POC Domain Layer und Saga Pattern für Events
Warum
Die Events um einen Case herum sind insbesondere nach der BiDiKo der Kernbestandteil unseres Systems. Es gab hier allerdings keine saubere Trennung von verschiedenen Konzepten, in verschiedene Richtungen (Primary/Secondary Ports).
Die Idee ist hier verschiedene DDD Pattern in ein Domain Layer zu packen um die Fachlichkeit klar abzugrenzen.
Danach kann die Abbildung in der Datenbank verbessert werden aus Performance gründen. Dann sollte die API um eine echte Event-History mit Timestamp erweitert um eine bessere und wenigere belastende alternative zum Polling anzubieten.
Ziel
Der Code befindet sich in einem Domain Layer der nur über Interfaces mit der Außenwelt kommuniziert.
Das bedeutet:
- Domain Layer
- Saga Pattern
- Domain Events
- Primary Ports (API)
- Secondary Ports (Webhooks/Callbacks)
- Repositories
Links, Hinweise, Bemerkungen
Es sollte ein POC geschrieben werden um den Domain Layer dem Team vorzustellen.
Stories
- Domain Layer wird eingezogen wie oben beschrieben, die Domain Logik kann getestet werden und das CaseSaga kann alle Events in alle Richtungen abarbeiten. Es soll keine Regressionen in Datenbank oder API geben alles wird abstrahiert.
- Domain Events werden neu in der Datenbank abgebildet, Fokus auf Effizienz und Performance (Snapshotting ggf. später falls nötig).
- Es gibt eine neue API Schnittstelle als alternative zum Polling, die entweder komplette Events ausliefert oder Referenzen zu Submissions.
Akzeptanzkriterien
-
Events sind eigene Klassen und werden in einer Saga Processed/Handled alles in einem Domain Layer. -
Die Abstraktion im Infrastruktur Layer soll reduziert und hochskalierbar sein. -
Events können "Abgeholt" werden durch die API
Mögliche Folgeaktivitäten
- Snapshotting
- Domain layer als basis um Messages und Replies zusammenzuführen
- Mehr Logik über den Domain Layer laufen lassen nicht nur Events