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).
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 😅
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.
@@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 😃
@ 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.
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?
@@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
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).
@@olijaun Ja, guter Punkt.
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 😅
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.
@@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 😃
@ 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.
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?
@@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