Inventory Reservation Red–Green–Refactor
Vom ersten Bestandscheck zur atomaren und parallelitätssicheren Reservierung.
Inventory Reservation – Red Green Refactor
Zyklus 1 – positive Mengen und bekannte Bestände
Red Leere Positionen, Nullmengen und unbekannte Produktbestände mussten vor jeder Mutation abgewiesen werden.
Green Command-Validierung und InventoryItemNotFoundException sichern den äußeren Vertrag.
Refactor StockItem kapselt onHand, reserved und available.
Zyklus 2 – atomare Mehrpositionsentscheidung
Red Eine naive Schleife hätte Position A reserviert, bevor Position B als unzureichend erkannt wird.
Green Aggregation, vollständiges Laden und Vorprüfung laufen vor reserve.
Refactor Die Mutationsphase ist kurz und folgt direkt auf die grüne Gesamtprüfung.
Zyklus 3 – konfliktfeste Idempotenz
Red Wiederholungen konnten neue ReservationIds und neue Events erzeugen.
Green Repository und kanonischer SHA-256-Fingerprint unterscheiden identische und veränderte Wiederholungen.
Refactor Die Ergebnisabbildung wird für Reservieren und Freigeben gemeinsam genutzt.
Zyklus 4 – Freigabe
Red Stornierungen benötigten die exakt reservierten Produktmengen und durften nicht doppelt zurückbuchen.
Green InventoryReservation hält einen unveränderlichen Positionssnapshot und schützt RESERVED -> RELEASED.
Refactor Ein eigener Application Service orchestriert Rückführung und Ereignis.
Zyklus 5 – konkurrierende Reservierungen
Red Zwei parallele Anfragen konnten denselben Restbestand lesen und beide erfolgreich sein.
Green InventoryTransactionRunner serialisiert die Gesamtentscheidung.
Refactor Locking bleibt im Adapter; Use Case und Domain kennen keine Threading-API.