Gesamtwerk

Fachliche Gleichheitsprüfung – Gesamtwerk

Alle 36 Szenarien, semantischen Zuordnungen, Abweichungen und Nachweise in einer Datei.

offlineEin-Datei-Gesamtwerk36 Szenarien
Ergebnis

Fachliche Gleichheitsprüfung

Ergebnis

Die drei Projekte sind nicht vollständig fachlich gleich. Von 36 verbindlichen Akzeptanzszenarien sind 7 in allen drei Varianten direkt verifiziert, 7 teilweise angeglichen und 22 besitzen mindestens eine Implementierungslücke.

Ergebnis Szenarien
Vollständig gleich 7
Teilweise angeglichen 7
Lücke in mindestens einer Variante 22

Die Prüfung ersetzt keine fehlende Implementierung durch eine positive Behauptung. Fachliche Gleichheit wird nur vergeben, wenn alle drei Varianten dasselbe beobachtbare Ergebnis nachweisen.

Bewertungslogik

  • VERIFIED Ausführbarer Test, Smoke-Check oder belastbarer Struktur- und Regelbeleg vorhanden.
  • PARTIAL Fachlicher Kern vorhanden, aber End-to-End-Nachweis, identische Statusbedeutung oder ein Teilaspekt fehlt.
  • NOT_IMPLEMENTED Kein ausführbarer Nachweis im Projekt.

Vollständig gemeinsamer Kern

Die sieben vollständig gleichen Szenarien liegen in Bestellung, Bestand und Zahlung

  • gültige Bestellung mit mindestens einer Position
  • unveränderliche Preis- und Produkt-Snapshots
  • Reservierung ohne negativen Bestand
  • idempotente Reservierungswiederholung
  • erfolgreiche Zahlungsautorisierung
  • fachliche Zahlungsablehnung ohne technischen Retry
  • idempotente Zahlungswiederholung

Konsequenz

Der Architekturvergleich vergleicht Architektur und Entwicklungsansatz auf Basis dieses ehrlichen Prüfstands. Nicht implementierte Fachlichkeit wird als Scope- und Reifegradunterschied ausgewiesen, nicht als Architekturvorteil oder -nachteil umgedeutet.

Szenariomatrix
SzenarioLayeredTDD-FirstDDDGesamtergebnis
AC-CUS-001
UC-01
VerifiziertVerifiziertNicht umgesetztGAP
AC-CUS-002
UC-01
VerifiziertVerifiziertNicht umgesetztGAP
AC-CUS-003
UC-01
VerifiziertVerifiziertNicht umgesetztGAP
AC-CAT-001
UC-02
VerifiziertVerifiziertNicht umgesetztGAP
AC-CAT-002
UC-02
VerifiziertVerifiziertNicht umgesetztGAP
AC-CAT-003
UC-02
VerifiziertVerifiziertNicht umgesetztGAP
AC-ORD-001
UC-03
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-ORD-002
UC-03
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-ORD-003
UC-03
VerifiziertVerifiziertTeilweisePARTIAL ALIGNMENT
AC-ORD-004
UC-03
VerifiziertVerifiziertTeilweisePARTIAL ALIGNMENT
AC-INV-001
UC-04
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-INV-002
UC-04
VerifiziertVerifiziertTeilweisePARTIAL ALIGNMENT
AC-INV-003
UC-04
TeilweiseVerifiziertTeilweisePARTIAL ALIGNMENT
AC-INV-004
UC-04
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-PAY-001
UC-05
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-PAY-002
UC-05
VerifiziertVerifiziertTeilweisePARTIAL ALIGNMENT
AC-PAY-003
UC-05
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-PAY-004
UC-05
VerifiziertVerifiziertVerifiziertEQUIVALENT
AC-BIL-001
UC-06
VerifiziertVerifiziertNicht umgesetztGAP
AC-BIL-002
UC-06
VerifiziertVerifiziertNicht umgesetztGAP
AC-BIL-003
UC-06
VerifiziertVerifiziertNicht umgesetztGAP
AC-FUL-001
UC-07
Nicht umgesetztVerifiziertNicht umgesetztGAP
AC-FUL-002
UC-07
Nicht umgesetztVerifiziertNicht umgesetztGAP
AC-FUL-003
UC-07
Nicht umgesetztVerifiziertNicht umgesetztGAP
AC-NOT-001
UC-08
Nicht umgesetztNicht umgesetztNicht umgesetztGAP
AC-NOT-002
UC-08
Nicht umgesetztNicht umgesetztNicht umgesetztGAP
AC-NOT-003
UC-08
Nicht umgesetztNicht umgesetztNicht umgesetztGAP
AC-CAN-001
UC-09
Nicht umgesetztNicht umgesetztVerifiziertGAP
AC-CAN-002
UC-09
Nicht umgesetztNicht umgesetztTeilweiseGAP
AC-CAN-003
UC-09
Nicht umgesetztNicht umgesetztNicht umgesetztGAP
AC-CAN-004
UC-09
Nicht umgesetztNicht umgesetztTeilweiseGAP
AC-ERR-001
UC-10
TeilweiseVerifiziertVerifiziertPARTIAL ALIGNMENT
AC-ERR-002
UC-10
TeilweiseVerifiziertVerifiziertPARTIAL ALIGNMENT
AC-ERR-003
UC-10
Nicht umgesetztVerifiziertVerifiziertGAP
AC-ERR-004
UC-10
Nicht umgesetztTeilweiseTeilweiseGAP
AC-ERR-005
UC-10
Nicht umgesetztNicht umgesetztNicht umgesetztGAP
Semantik

Status-, Ereignis- und Fehlersemantik

Vergleichsprinzip

Gleichheit wird nach fachlicher Bedeutung bewertet. Unterschiedliche Klassennamen sind zulässig; unterschiedliche Wirkung, Idempotenz oder Fehlerklassifikation sind es nicht.

Status

  • DDD modelliert einen expliziten Entwurf vor PLACED; Layered und TDD erzeugen die Bestellung direkt als PLACED.
  • Reservierungs- und Zahlungsstatus liegen je nach Architektur im Order-Zustand, in einem Lifecycle Store oder in getrennten Aggregaten mit Process Manager.
  • Diese Unterschiede sind architektonisch, solange das externe Ergebnis gleich bleibt.

Ereignisse

  • DDD übersetzt Domain Events in versionierte Integration Events.
  • InventoryRejectedV1 entspricht fachlich InventoryReservationRejected.
  • PaymentRejectedV1 entspricht fachlich PaymentDeclined.
  • Für Billing, Fulfillment, Notification und vollständige Cancellation fehlen je nach Variante Ereignisse oder ganze Use Cases.

Fehler

  • Fachliche Ablehnung und technische Störung sind in allen drei Payment-Varianten grundsätzlich getrennt.
  • DDD besitzt noch keine vollständige kanonische REST-Fehlerabbildung für alle gemeinsamen Fehlercodes.
  • Idempotenz ist in DDD auf Aggregate- und Eventebene vorhanden, der gemeinsame IdempotencyKey von Place Order jedoch nicht vollständig äquivalent.
Abweichungen

Abweichungen und Entscheidungen

GAP-01 – Customer und Catalog in DDD

Auswirkung 6 Szenarien
Entscheidung Nicht als vollständig gleich markieren. Supporting Contexts sind strategisch beschrieben, aber nicht implementiert.

GAP-02 – Notification

Auswirkung 3 Szenarien in allen Varianten
Entscheidung Gemeinsamer fachlicher Scope ist spezifiziert, aber in keinem der drei Projekte ausführbar umgesetzt.

GAP-03 – Cancellation

Auswirkung 4 Szenarien
Entscheidung DDD besitzt lokale Order-Stornierung; Bestandsfreigabe, Payment Void und SHIPPED-Sperre sind nicht vollständig orchestriert.

GAP-04 – Fulfillment

Auswirkung Layered und DDD fehlen; TDD vollständig
Entscheidung Kein künstlicher Gleichheitsstatus. Unterschied bleibt für den Architekturvergleich sichtbar.

GAP-05 – Billing in DDD

Auswirkung 3 Szenarien
Entscheidung DDD-Referenz fokussiert Ordering, Inventory und Payment; Rechnungskontext bleibt offen.

GAP-06 – Payment Recovery

Auswirkung Retry und Late Result nicht durchgängig
Entscheidung Retry-Kern vorhanden; finaler, contextübergreifender Recovery-Prozess ist nur teilweise implementiert.

GAP-07 – Parallelitätsnachweis

Auswirkung Layered und DDD teilweise
Entscheidung Locking/Versionierung sind vorhanden, vollständige konkurrierende Datenbanktests konnten ohne Containerlauf nicht bestätigt werden.

Prüfnachweis

Prüfnachweis

Umfang

  • 36 verbindliche Akzeptanzszenarien
  • 108 Einzelbewertungen über drei Projekte
  • 10 Use Cases
  • Status-, Ereignis- und Fehlersemantik
  • vorhandene Test-, Smoke- und Architekturbelege

Architekturstände

Projekt Verified Partial Nicht implementiert
Layered 20 3 13
TDD-First 27 1 8
DDD 11 8 17

Automatisierte Kontrollen

  • Referenzmatrix enthält genau 36 eindeutige Szenarien.
  • Jede der 108 Bewertungen besitzt einen zulässigen Status.
  • Jeder positive oder teilweise positive Status verweist auf einen vorhandenen Nachweis.
  • Die sieben vollständig gleichen Szenarien werden aus den Einzelbewertungen berechnet.
  • Keine offene PENDINGBewertung bleibt bestehen.
  • HTML-Navigation, lokale Links, Offlinefähigkeit und interne Quelltrennung werden geprüft.

Einschränkung

Der Audit nutzt vorhandene ausführbare Tests, Java-21-Smoke-Checks und statische Evidenz. Ein vollständiger Maven- und Containerlauf aller drei Projekte war in der Erzeugungsumgebung weiterhin nicht möglich.

Darstellung

Design
Text
Dichte
⌂ Cockpit