Domain-Driven Design: Ein vollständiges Beispiel 2/2

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können.
In dieser Episode geht es um taktisches Design, CQRS, Event Sourcing und hexagonale Architektur.
Links
Training Domain-driven Design saniert Legacy www.socreatory...
Folien speakerdeck.co...
Taktisches Domain-driven Design (DDD) software-archi...
Taktisches Domain-Driven Design mit Java und jMolecules mit Oliver Drotbohm software-archi...
Folgen zu Architecture Management software-archi...
Events, Event Sourcing und CQRS software-archi...
Video zu Kafka als Datenbank-Monolith • Kafka - The New Databa...
Christian Stettler: Domain Events vs. Event Sourcing - Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten www.innoq.com/...
Vaughn Vernon about Ports and Adapters and DDD software-archi...

[@olijaun]

Noch eine Bemerkung zu CQRS: Ich finde die Command Queue im Diagram unnötig. Klar kann man das machen, wenn man will. CQRS setzt aber nicht voraus, dass Commands in eine Queue kommen oder gar persistiert werden. Was persistiert werden muss, ist lediglich das Ergebnis des Commands (also z.B. ein Event).

[@EberhardWolff]

@@olijaun Ja, guter Punkt.

[@marcm3623]

Hallo Eberhard, Frage zu 9:52 bis 10:34 Über die Logik: Man steht vor einem Projekt und muss herausfinden ob das vorgegebene Projekt eine geschäftslogik hat. Welche Fragen muss ich stellen um das heraus zu finden? Und was ist der nächste Schritt, wenn ...man geschäftslogik hat ...man keine geschäftslogik habe. Und letzte Frage was trinkst du da 😅

[@EberhardWolff]

Die Geschäftslogik sollte durch die Requirement klar sein. Wenn dort Berechnungen, komplexe Abläufe usw. definiert sind, gibt es Geschäftslogik. Eigentlich sollte das Event Storming als Big Picture und Design Level die Abwesenheit oder Anwesenheit von Geschäftslogik klar erkennbar machen.

[@marcm3623]

@@EberhardWolff also wird die Frage nach Anwesenheit und Detaillierung-Grad der geschäftslogik beim Event storming beantwortet.(?) Aber die requirements kommen doch nicht beim Event storming in Erscheinung sondern vorher oder? Beim Pflichtenheft? Ich bin durch mit meinen Fragen für heute mehr kommt nicht 😃

[@EberhardWolff]

@ Meine Hoffnung wäre, dass Entwickler:innen an der Stelle, wo sie sich mit der Inplementierung beschäftigen, die Geschäftslogik soweit kennen, dass sie das richtige Pattern auswählen können. Sonst haben sie keinen Plan, was zu implementieren ist und werden dementsprechend nix implementieren.

[@olijaun]

Ich verstehe die Bemerkungen zu Event Sourcing im Zusammenhang mit der Lieferung nicht. "Was habe ich jetzt davon das es berechnet wird?" Es geht bei Event Sourcing darum, dass der aktuelle (oder ein früherer) Zustand aus den vergangenen Events wiederhergestellt wird. Wieso sollte ich das sonst noch irgendwo speichern? Klar, ich will das vielleicht zwecks Abfrage noch in einem Read Model haben. Ich verstehe das Problem nicht. Wo möchte ich den Zustand nicht rekonstruieren?

[@EberhardWolff]

@@olijaun Wenn man den Zustand rekonstruieren will, dann ist ES die Lösung. Ob ich das will, ist eine fachliche Frage - es muss eine Anforderung geben. Den Zustand nicht zu speichern, sondern immer nur zu berechnen finde ich eher selten sinnvoll. Mehr Infos gibt es in der Episode zu Events software-architektur.tv/2022/04/22/folge116.html