Place Order Red–Green–Refactor
Vom permissiven Walking Skeleton zum fachlich geschützten Bestellablauf.
Place Order – Red Green Refactor
Zyklus 1 – aktiver Kunde
Red Der bestehende Walking Skeleton akzeptierte jede CustomerId.
Green CustomerOrderingSource prüft die tatsächlich registrierte Identität.
Refactor CustomerRepositoryOrderingSource hält das Customer-Modell außerhalb des Ordering-Use-Cases.
Zyklus 2 – Produkt-Snapshots
Red Der alte Preisport lieferte nur einen Betrag und konnte weder Aktivstatus noch Bezeichnung nachweisen.
Green ProductOrderingSource liefert einen bestellbaren ProductSnapshot.
Refactor OrderLine besitzt Snapshot und Quantity als Value Objects.
Zyklus 3 – Zustandsübergang
Red Der frühere OrderRecord war sofort PLACED und zeigte keine Invariante des Übergangs.
Green Order.draft, addLine und place modellieren den Ablauf.
Refactor Nach PLACED sind weitere Positionsänderungen gesperrt.
Zyklus 4 – Idempotenz
Red Wiederholungen erzeugten neue OrderIds und neue Ereignisse.
Green Repository und Request-Fingerprint erkennen identische Wiederholungen.
Refactor SHA-256-Fingerprint bleibt eine interne technische Hilfe; die fachliche Entscheidung liegt im Use Case.
Zyklus 5 – integrierter HTTP-Nachweis
Customer und zwei Produkte werden über ihre realen HTTP-Endpunkte registriert. Anschließend werden Erfolg, Wiederholung, Konflikt, unbekannter Kunde, unbekanntes Produkt und leerer Warenkorb über /api/v1/orders geprüft.