Nicole Rauch zu DDD, Event Storming & Specification by Example

Diese Woche ist Nicole Rauch zu Gast. Mit Event Storming kann man Domain-driven Design ganz praktisch und kollaborativ umsetzen. Und Specification by Example stellt sicher, dass man auch das richtige baut.
Buch-Tipp: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing von Gojko Adzic / bridging-the-communica...
41:42 Specification by Example

[@christophbaudson1461]

Specification by example ab 41:42

[@EberhardWolff]

Danke, ich habe den Timecode in der Beschreibung des Videos ergänzt. 👍

[@wazum]

20:06 „Information aus der ich das entnehmen kann ist immer ein Event.“ braucht vielleicht noch mehr Erklärung. Events sind Ereignisse, die passiert sind und danach ist das Event (aus meiner Sicht) vergangen. Was ist damit gemeint, dass man aus einem Event Informationen holen kann? Ein Event verrät mir doch nicht den Lagerstand eines Artikels(?) Daten beziehe ich aus den persistierten Daten über ein Repository. Events mögen dazu führen, dass diese Daten sich verändern, aber ein Event liefert per se keine vollständigen Informationen.

[@nicolerauch4068]

Der Ereigniszeitpunkt mag vergangen sein, aber das Event im Sinne von EventStorming beschreibt eine Änderung innerhalb meiner Domäne, und diese Änderung hat Auswirkungen, meist bis in die Gegenwart. (Ohne Auswirkungen wäre es kein sinnvolles Event.) Das heißt "aus dem Event Informationen holen" ist auf einer abstrakten nicht-technischen Ebene gemeint: Das Event hat gewisse Änderungs-Informationen ins System eingebracht, und diese Informationen kann ich später verwenden. Da mich das "Dazwischen" nicht interessiert, spreche ich oft verkürzend von "aus dem Event entnehmen". Es tut mir leid, falls das zu Verwirrung geführt hat. Natürlich werden diese Änderungs-Informationen üblicherweise irgendwo festgehalten, zum Beispiel durch Änderung eines Wertes in einer relationalen Datenbank, oder durch Speichern des Events in einem Eventstore (bei Verwendung von EventSourcing), oder durch Notieren auf einem Zettel (wenn ich einen manuellen Prozess mit Hilfe von EventStorming abbilde). Die konkrete technische Ausprägung ist für uns im EventStorming nicht relevant. Aber das Wichtige ist, dass es immer ein Event ist, das eine solche Änderung auslöst. "Ein Event verrät mir doch nicht den Lagerstand eines Artikels(?)" -> Wenn ich die Events "Palette mit 20 Stück wurde ins Lager eingebucht" und "Ein Stück wurde verkauft" definiert habe, kann ich, indem ich alle Vorkommen dieser beiden Events (seit Anbeginn des Systems) zusammenfasse, den aktuellen Lagerbestand bestimmen. Wenn mir eins (oder beide) dieser Events fehlt, kann ich das an einer Verwendungsstelle des Lagerbestands bemerken, weil ich den Lagerbestand nicht korrekt aus Events ermitteln kann. Dann kann ich das System um die fehlenden Events ergänzen. Ich hoffe, das Ganze ist jetzt ein bisschen klarer geworden? Ansonsten gerne nochmal nachfragen!

[@wazum]

@@nicolerauch4068 Ja, danke, damit kann ich mit den Aussagen mehr anfangen!