Layered REST und Integration
Implementierung innerhalb des eigenständigen Layered-Projekts.
Layered REST und Integration
Ziel
Die Integrationsstufe macht die bisherige Layered-Implementierung über den gemeinsamen HTTP-Vertrag erreichbar und liefert die bereits transaktional vorgemerkten Business Events an Kafka oder Redpanda aus. Der Fachkern bleibt unverändert frameworkfrei.
Umgesetzter vertikaler Ablauf
HTTP JSON
→ Controller
→ DTO-Mapper
→ Application Service
→ Repository- und Gateway-Ports
→ PostgreSQL + Outbox in einer Transaktion
→ geleaster Outbox-Dispatcher
→ Kafka/RedpandaREST-Ergebnis
| Use Case | Endpunkt | Erfolg |
|---|---|---|
| UC-01 | POST /api/v1/customers |
201 Created |
| UC-02 | POST /api/v1/products |
201 Created |
| UC-03 | POST /api/v1/orders |
201 Created |
| UC-04 | POST /api/v1/orders/{orderId}/inventory-reservations |
200 OK |
| UC-05 | POST /api/v1/orders/{orderId}/payment-authorizations |
200 OK |
| UC-06 | POST /api/v1/orders/{orderId}/invoices |
201 Created |
Fehlersemantik
Fachliche Fehler werden durch einen zentralen Exception Translator in Problem Details überführt. Stabile Fehlercodes, HTTP-Status, Retry-Hinweis, Instanzpfad und Korrelationskennung bleiben voneinander getrennt.
Event-Auslieferung
Die Outbox wurde um Leasing erweitert. Ein Worker beansprucht eine begrenzte Menge von Datensätzen, kennzeichnet sie als IN_FLIGHT und bestätigt sie erst nach Broker-Acknowledgement. Abgelaufene Leases können erneut übernommen werden. Nach Erreichen der maximalen Versuche wird ein Datensatz als FAILED markiert.
Lokaler Runtime-Stack
PostgreSQL und Redpanda werden über Docker Compose gestartet. Das lokale Spring-Profil verwendet ein deterministisches Payment-Gateway-Fake. Außerhalb des lokalen Profils steht ein HTTP-Gateway als Anti-Corruption Layer bereit.
Ergebnis
REST, Persistenz und Messaging bleiben getrennte äußere Adapter. Die Zusammensetzung erfolgt ausschließlich im Bootstrap-Modul.