Durch Eventmodeling zerteilt das Team die Software in die kleinstmöglichen vertikalen Funktionsblöcke. Wir nennen diese Blöcke "Slices".

Slices bestehen aus Commands (Blau), Events (Gelb) und Read Modellen (Reports) (Grün). Das Team bringt die ersten Events in eine grobe Reihenfolge und definiert direkt den ersten Slice für die Anmeldung des Benutzers

Was jeden erstaunt - der Workshop ist äusserst produktiv und es werden genau die richtigen Diskussionen zwischen den Teilnehmern geführt.

Was ist die Reihenfolge der Events?
Was muss im Screen zu sehen sein?
Was sind die Schritte, die nacheinander gemacht werden müssen?
Wo kommen die Daten her?

Das Team benötigt lediglich 5 Minuten um produktiv zu arbeiten. Das Format ist quasi selbsterklärend.

Modellvalidierung

Was dem Team extrem hilft ist die Echtzeitvalidierung des Modells. Fehlerhafte oder fehlende Daten werden direkt rot markiert. So ist sofort klar, welches Slice direkt fertig ist und wo noch weitergearbeitet werden muss.

Im Workshop selber kommen immer wieder Fragen auf, die der Berater kurz und knapp beantwortet. Ansonsten hält sich dieser meist im Hintergrund und stellt nur Fragen, wenn Diskussionen ins Stocken geraten.

Eine Frage, die beispielsweise mehrfach gestellt wurde ist "Wie gehen wir mit generierten Werten wie beispielsweise einer SessionId um?" Den Vorschlag des Beraters siehst du im Video.

Der erste Aha-Moment

Read Modelle (oder auch Reports) sind die Art und Weise wie Daten zwischen Slices weitergereicht werden. Die Read Modelle sind im Event-Modell grün markiert. Die Daten werden aus den zuvor gespeicherten Events befüllt.

Der erste Aha-Moment

Hier kommen die ersten wirklichen Aha-Momente. Moritz dem Architekten wird in diesem Moment klar, was durch diese Art der Modellierung wirklich erreicht wird. Der "Registrierungs-Slice" ist ein in sich geschlossesenes Feature.

Das Team hat für dieses Feature klare Eingangs- und Ausgangsparameter definiert. Das Feature könnte jetzt bereits implementiert werden, da keinerlei unbekannte Abhängigkeiten existieren.

Durch die Modellierungen hat das Team einen eingebaute Daten-Komplett-Check.. Es kann nicht passieren, dass auf Daten zugegriffen wird, die nicht vorhanden sind. Es gibt keinerlei Annahmen, sondern nur Fakten.

Der Berater erklärt immer wieder, dass aus den Screens in den Slices eigentlich jeder dynamische Wert ersichtlich sein muss. Es sollte für einen Entwickler auf den ersten Blick ersichtlich sein, wo die Dynamik im Screen ist.

Nachträgliche Anpassung von Features

Jens, ein Teilnehmer und Entwickler stellt eine wichtige Frage.

Haben wir nicht was vergessen? Wo kommt der Titel der Produkte her?

Jeder ist kurz verblüfft. Tatsächlich ist das bisher niemandem aufgefallen. Das Modell lässt sich natürlich problemlos jederzeit erweitern.

Die Änderung ist meistens auf einen Slice begrenzt. Das Team muss lediglich sicherstellen, dass die notwendigen Daten verfügbar sind. Die Modellvalidierung hilft dabei enorm.

Das Team geht jetzt Schritt für Schritt durch die einzelnen Slices. Es finden wichtige Diskussionen statt. Schritt für Schritt wird klar, welche Daten in welchem Schritt der Software benötigt werden.

Das Team trifft zu keiner Zeit Annahmen, sondern arbeit alleine auf Fakten und Daten.

Während ein Teil des Teams noch die Daten für die Events und Commands definiert, kann ein weiterer Teil bereits das Screendesign für den nächsten Screen erstellen.

Die Arbeit ist komplett parallelisierbar (hier in der Modellierung, aber auch später in der Implementierung).

Lego Slices - das vorerst letzte Feature.

Slices können zusammengesteckt werden wie Lego-Bausteine. Das Team entscheidet sich, zunächst nicht die gesamte Software zu modellieren. Alle Teilnehmer einigen sich auf eine Menge von Slices, die in einem Sprint umgesetzt werden kann.

Das Team kann zu jeder Zeit mit der Modellierung fortfahren, ohne dass Information verloren geht.

Swimlanes

Im letzten Schritt definiert das Team die ersten Swimlanes. Durch Swimlanes bekommen wir eine Zuordnung der Events und Daten zu den Kontexten unserer Software. Swimlanes entsprechen im Domain Driven Design in etwa den Bounded Kontexten. Eine Swimlane kann einen eigenen Service, ein Modul oder nur einen eigenständigen fachlichen Bereich repräsentieren.