Event Storming – Gemeinsam die Domäne entdecken

In der Praxis treten innerhalb von Projekten häufig Schwierigkeiten auf, die auf unklare oder unscharfe Abgrenzung von Fachlogik zurückzuführen sind. Ursache häufig: die Problemdomäne ist für den Kunden nicht immer klar, oder von vornherein wurde die Domäne viel zu groß oder am eigentlichen Problem vorbei abgesteckt. Mitunter entstehen dadurch Probleme beim Laufzeitverhalten – häufige, gegenseitige Aufrufe von Microservices, Nebenläufigkeitsprobleme, hohe Latenzzeiten etc. – die erhebliche Nachbesserungen und Behebungskosten nach sich ziehen.
Im Extremfall ist das ganze Unternehmen als „kanonisches Datenmodell“ umgesetzt – ein absolutes Anti Pattern für moderne Microservice-Architekturen. Und natürlich kann es zu fundamentalen Missverständnissen zwischen Fachabteilung und Entwicklern kommen, welche dazu führen, dass ein Projekt komplett am eigentlichen Ziel vorbei entwickelt wird.

Durch die Methoden des Domain Driven Designs sollen solche Probleme vermieden werden. Es gilt, zunächst ein gemeinsames Bild von der Fachlichkeit zu finden und ein von technischen Details möglichst befreites Modell zu entwickeln, auf das in der Folge die gesamte Systemarchitektur ausgerichtet wird. Ein sinnvoller erster Schritt auf dem Weg dorthin ist Event Storming (auch: EventStorming). Von Alberto Brandolini entwickelt, erfreut sich dieses Workshop-Format großer Beliebtheit, und das Interesse an Event Storming steigt in den letzten Jahren deutlich (siehe Bild 1).

Das Ziel von Event Storming

Ziel von Event Storming ist es, ein gemeinsames Verständnis für die Domäne(n) zu erlangen, sowie eine gemeinsame Sprache aller an der Entwicklung beteiligten Fachleute und Softwarespezialisten zu definieren, die „Ubiquitous Language“. Über die einzelnen Abteilungs-Silos hinweg werden Business Cases modelliert und für alle Beteiligten sichtbar und verständlich gemacht. Probleme und Bottlenecks können identifiziert und die wichtigsten Bestandteile eines Business-Prozesses herausgefunden werden – z.B. für die Entwicklung eines MVPs.

Das sichtbare Ergebnis des Workshops (siehe Bild 2) ist ein großflächiges Bild der Prozesse und ihrer umgebenden Kontexte, jedoch stellt dies eher einen Anfangs- als einen Endpunkt dar: Man muss klarstellen, dass kein finales Modell der Domäne zu erwarten ist, sondern immer nur ein „Snapshot“ der mit den Teilnehmern und dem aktuellen Wissensstand entwickelten Sicht auf das fachliche Problem. Das eigentliche Domänen-Modell entsteht später innerhalb des Codes der Anwendung.

Noch wichtiger ist aber, dass losgelöst vom Artefakt ein einheitliches Wording für die verschiedenen Konzepte innerhalb der identifizierten Domänen entsteht. Durch den initialen Fokus auf Events wird die Komplexität maximal reduziert, und es kann sich leicht auf die ablaufenden Prozesse konzentriert werden. Entwicklungsteams können so schnell in eine Domäne eingearbeitet werden, und durch den Austausch mit den Domänenexperten frühzeitig Unklarheiten klären oder vermeiden.

Der Workshop in Kürze

Innerhalb eines codecentric-internen Trainings unter Anleitung von Tobias Goeschel konnten wir erste Erfahrungen mit Event Storming sammeln. Dabei wurde ein (fiktives) Szenario als Rollenspiel modelliert und durch die 4 grundlegenden Schritte von Event Storming vertieft: 

• Big Picture
• The Picture That Explains Everything
• Process Modelling
• Software Design

Im Folgenden beschreibe ich kurz meine dabei gesammelten Eindrücke und Erkenntnisse.

Das Setup

Eine Stärke des Event Stormings ist, dass fachliche Experten (Stakeholder, POs, evtl. Nutzer) und Entwickler im selben Raum sind. Dabei ist auf eine gleichmäßige Verteilung zu achten: Es sollten annähernd die gleiche Anzahl Fachexperten und Implementierer anwesend sein. Idealerweise umfasst die Gruppe nicht mehr als 15 Personen, der “Sweet Spot” liegt bei etwa der Hälfte, also 8-10 Personen.

Der Moderator stellt am Anfang des Workshops eine “unendlich” große Fläche zur Verfügung (z.B. auf einer Papierrolle), um später darauf die Klebezettel platzieren zu können. Ein Raum mit viel glatter Wandfläche ist hierfür am besten geeignet. Dazu wird eine ebenfalls “unendliche” Anzahl an Klebezetteln in unterschiedlichen Farben und Ausprägungen, sowie passende Stifte, für die Teilnehmer bereitgestellt.

Die Wandfläche repräsentiert – in der Regel von links nach rechts – den zeitlichen Horizont für die zu entdeckenden Prozesse. Klebezettel sind als Modellelemente ideal, denn man kann sie frei sortieren, verschieben und wegschmeißen. Nichts ist “in Stein gemeißelt” – im Gegenteil werden im Laufe des Workshops immer wieder Teile des Modells verworfen, verschoben oder erweitert. Der Moderator greift in die Diskussionen nur minimal lenkend ein, um den Workshop erfolgreich ins Ziel zu führen, lässt aber ansonsten den Teilnehmern möglichst viel Freiraum. Eine Legende mit den verschiedenen „Building Blocks“ des Workshops entsteht während der Arbeit und steht jederzeit zur Verfügung.

Das Vorgehen

Das Vorgehen zu Beginn des Event Storming Workshops ist explorativ und bewusst nicht darauf ausgelegt, dass von Anfang an alles „perfekt“ wird. Das Wording muss noch nicht immer stimmen, die Events – zunächst der einzige verfügbare Baustein – nicht immer „korrekt“ formuliert sein. Wichtig ist, dass der Einstieg leicht fällt, und dadurch die Gruppe schnell in einen Flow kommt und kreativ aktiviert wird. Die Domäne wird anschließend iterativ erkundet und das Modell Schritt für Schritt immer weiter ausgearbeitet. Im weiteren Verlauf des Workshops stellt der Moderator nach und nach weitere Tools und Bausteine zur Verfügung, um die Teilnehmer nicht mit Informationen zu überladen. Dies hat den Nebeneffekt, dass durch veränderte Bedingungen auch unterschiedliche Aspekte der Fachlichkeit beleuchtet werden, was Schärfung und Detailreichtum des Modells fördert.

„The Big Picture“

Der Workshop startet damit, dass die Aufgaben der Teilnehmer klargestellt werden: Die Domänenexperten dürfen Ereignisse auf Klebezettel schreiben, die Entwickler müssen sie auf der Modellfläche platzieren und in eine sinnvolle Reihenfolge bringen. Werden diese „falsch“ angebracht, sollen die Fachexperten einschreiten und verbessern. Sind Zusammenhänge unklar, werden durch die Entwickler Fragen gestellt und von den Experten beantwortet. Alle sollen dabei ausgiebig miteinander über die Events diskutieren, diese in Frage stellen und Verbesserungsvorschläge machen.

Zuerst werden – wie bereits angedeutet – nur Domain Events auf der Fläche verteilt: Fachliche Ereignisse, die im zu erkundenden Problemraum zu beobachten sind. Den Anfang zu machen, ist dabei vielleicht das Schwerste – der Moderator kann etwas nachhelfen. Danach kommt man schnell in eine regelrechte Flut von neuen Events, welche zeitlich vor, parallel zu, oder nach dem ersten Event stattfinden.

Natürlich können „falsche“ (also vermeintlich schlecht benannte) oder doppelte Events angebracht werden. Der Moderator kann darauf hinweisen, dass diese Events nicht unbedingt der Konvention entsprechen, aber sollte nicht unbedingt dadurch den Fluss an neuen Events verlangsamen. Wichtig ist, ein ganzheitliches Bild des Prozesses zu erlangen. Später können Events nachgeschärft oder verbessert werden.

Teile des Prozesses werden größere Diskussionen auslösen: über Probleme, Risiken oder Entscheidungen. Man kann diese mitHot-Spot-Zetteln (in lila) markieren, welche später genauer betrachtet oder nochmal geklärt werden müssen. Auf diese Weise werden allzu lange Pausen vermieden und der Arbeitsfluss bleibt konstant schnell.

Je größer das Bild wird, um so mehr bilden sich auch zusammenhängende Ketten und „Cluster“ heraus, die mittels Klebezetteln deklariert und benannt werden können.

Am Ende des „Big Picture“ ist ein Überblick über das „große Ganze“ entstanden – die Gruppe hat eine Vorstellung der Dimensionen und Zusammenhänge entwickelt und bereits jetzt viele Abstimmungen und Einigungen erzielt.

„The Picture That Explains Everything“

Sobald sich ein klareres Bild ergibt, der Fluss an neuen Events langsamer wird und auch die Diskussionen weniger werden, stellt sich die Frage nach dem Ursprung der Ereignisse: Akteure  (Strichmännchen) werden identifiziert und benannt, sowie „Commands“, also Befehle, eingeführt. Dabei gilt der Befehl nicht etwa anderen Akteuren, sondern ergeht an das System. Ein Befehl verändert den Systemzustand – und die Veränderung wird als Ereignis sichtbar.

Durch die Einführung der neuen Elemente entstehen neue Diskussionen, es wird ein verfeinertes Bild der Abläufe erzeugt. Ein Command kann durch verschiedene (auch mehrere) Akteure ausgelöst werden, welche aus ganz unterschiedlichen Gründen eine Entscheidung treffen. Es stellt sich ggf. heraus, dass einige Events unnötig sind, oder andere wiederum unter falschen Annahmen erstellt wurden. Es beginnt ein stetiges Herausfordern der vorherigen Annahmen über die Prozesse.

Zum Treffen von Entscheidungen werden Daten benötigt – Read Models werden eingeführt.

Nun können die benötigten Informationen spezifiziert und diskutiert werden. Interessant ist hier, dass der Fokus vollständig auf der Verwendung der Daten liegt, nicht auf deren Erfassung oder Speicherung – Stammdaten, Tabellen und Verknüpfungen sind Implementationsdetails und werden „ausgeblendet“. Es ergeben sich verblüffende Erkenntnisse über die Struktur und Relevanz der Daten, die signifikante Auswirkungen auf die Lösungsarchitektur haben können:

Aus diesen neuen Informationen lässt sich bspw. leicht eine Event-Driven Architecture ableiten. Man kommt einem ganzheitlichen Bild des späteren Modells für die einzelnen Prozesse immer näher.

Automatisierbare oder eindeutig regelbasierte Entscheidungen werden als „Policies“ markiert und benannt. Hier entfällt der Akteur, da das System eigenständig agieren kann. Die genauen Geschäftsregeln werden aber zunächst noch nicht eingepflegt, da dies sowohl die Übersichtlichkeit gefährden, als auch den Arbeitsfluss unterbrechen würde. Am Ende des Workshop-Abschnitts sollte jedem Event entweder ein Command oder eine Policy zugeordnet, alle benötigten Daten identifiziert und die Akteure benannt sein – damit ist „everything explained“, also der Gesamtzusammenhang erschlossen.

Es sollte zu diesem Zeitpunkt auch deutlich werden, welche Teilprozesse untereinander kommunizieren oder in zeitlichen Abhängigkeiten stehen. Außerdem können über gezeichnete Begrenzungen die einzelnen Prozesse isoliert werden, der Bounded Context wird sichtbar und bildet das Ergebnis dieses Schrittes.

Process Modelling

Als nächster Schritt werden die einzelnen Prozesse, bestehend aus Commands, Events, Policies usw. näher betrachtet und verfeinert. Es werden Namen für die Prozesse vergeben und Teilprozesse identifiziert. Die für die Benennung der einzelnen Bausteine verwendete Sprache wird noch einmal besonders kritisch geprüft, d.h. es wird z.B. auf eine bessere Namensgebung geachtet und Konsistenz hergestellt. Das kann erneut dazu führen, dass umgruppiert und ausgetauscht wird. Kernprozesse des Geschäftsmodells (Core Domain) werden von Hilfsdomänen (Supporting Domain, z.B. Notifications, Buchhaltung, Dokumentendruck) separiert und so der Blick auf das eigene Unternehmensprofil geschärft. Nicht zuletzt werden noch „externe Systeme“, wie bspw. Email oder Payment Provider, eingefügt und in die Prozesse mit einbezogen.

Software Modelling

Im letzten Schritt werden die Prozesse innerhalb eines Bounded Contexts aufgelöst und die darin enthaltenen Events und Commands nach ihrer Benennung gruppiert. Zusammengehörige Elemente („Vertrag aufgesetzt“, „Vertrag zugeschickt“, „Vertrag abgeschlossen“) weisen auf die grundlegenden Bausteine des Domänenmodells hin: Sogenannte „Aggregates“, d.h. in der Regel aus mehreren einfacheren Objekten zusammengesetzte Strukturen, die die wesentlichen Bestandteile der Geschäftslogik ausmachen (in diesem Fall: „Vertrag“). Diese Objekte kapseln Zustände und Transaktionen und bilden später in der Implementation die Grundstruktur des modularen Systems. Nun zahlt sich aus, wie akribisch der bisherige Workshop durchgeführt wurde: Je präziser die Benennung, umso leichter ist es, auf die richtigen Strukturen zu stoßen.

Objekte, die Aufgaben erledigen („Dokument drucken“, Vertrag drucken, “F„ormular drucken“), jedoch keinen eigenen Zustand enthalten, stellen die letzten noch fehlende Bausteine dar: Domain Services sind hier interne Dienste („DruckService“), die innerhalb des Domänenkerns verortet sind – im Gegensatz zu klassischen Services, die bekanntlich fertig implementierte Komponenten darstellen. Ihre Identifikation läuft analog und zeitgleich mit dem Entdecken der Aggregates, lediglich durch den Inhalt der Ereignisse und Commands wird die Unterscheidung deutlich.

Ausblick

Abschließend kann mit dem Gesamtergebnis aus identifizierten (Sub-)Domänen, Prozessen und Softwarebausteinen ein Plan für die Umsetzung erstellt werden: Es gilt, wichtige und unwichtige Prozessschritte zu finden, und diese voneinander zu isolieren. Einzelne Teilprozesse können dabei als Namensgeber für User Stories dienen, die in einem anschließenden Story Mapping Workshop den Start einer Produktumsetzung entscheidend erleichtern. Vor allzu großem Enthusiasmus über die Fülle der Ergebnisse sei jedoch an dieser Stelle noch einmal gewarnt: Während es in jedem Fall deutlich zu bevorzugen ist, eine Projektplanung auf den Ergebnissen aus dem Event Storming aufzubauen, als über ein im klassischen Requirements Engineering erarbeiteten Backlog (oder gar Pflichtenheft), so ist und bleibt das Modell eine – wenn auch detailreiche – Momentaufnahme. Während der Entwicklung ist es durchaus nicht ungewöhnlich, dass stellenweise nachkorrigiert oder auch mal größere Systemteile verändert werden müssen, wenn neue Erkenntnisse entstehen. Das lässt sich in komplexen Zusammenhängen weder vermeiden, noch wäre eine Vermeidungsstrategie wünschenswert. Vielmehr sollte in  regelmäßigen Abständen das Event Storming wiederholt und damit geprüft werden, ob das gemeinsame Bild immer noch mit dem letzten modellierten Stand kongruent ist, oder ob sich inzwischen Änderungen ergeben haben, die Berücksichtigung verlangen. Aber selbstverständlich kann dies auch durch viele andere Mechanismen erreicht werden. Es bietet sich mithin an, die Methoden zu variieren, da sich sonst möglicherweise Automatismen einschleichen, die die Ergebnisse verwässern.

Fazit

Durch das gemeinsame Brainstorming und das Reduzieren auf rein fachliche Events kann der Workshop manche Schwierigkeiten klassischer Softwareprojekte lösen: Die Einstiegshürde ist denkbar niedrig (jede*r kann am Workshop teilnehmen und auch ohne methodische Vorkenntnisse sofort produktiv einsteigen), der Wissenstransfer ist unmittelbar und umfassend. Doch es ist keineswegs nur ein Transfer in eine Richtung: Aus dem Zusammenspiel von Domänenexperten, Entscheidern, Entwicklern und Moderator können komplexe Zusammenhänge für alle Beteiligten erarbeitet und verfeinert werden. Nicht selten werden dabei Fehleinschätzungen und Missverständnisse aufgedeckt, die unerkannt über Jahre für Probleme sorgten.

Der Moderator führt während des Workshops Stück für Stück neue Konzepte ein, um die Diskussionen am Leben zu erhalten und gleichzeitig die Teilnehmer nicht mit Informationen zu überladen. Das sorgt für ein konstant hohes Energielevel und verblüffend detailreiche Ergebnisse.

Am Ende des Workshops herrscht ein gemeinsames Verständnis über die besprochene Domäne, und es kann nun ein erstes Modell erstellt und verifiziert werden. Dieses sollte im Verlauf des Projektes an neue Erkenntnisse und Learnings iterativ angepasst und immer wieder verfeinert werden.

Der Blogbeitrag vermag natürlich nur einen kurzen Überblick über Event Storming und dessen Durchführung zu geben. Den besten Einblick erhält der Leser beim Ausprobieren und Selbst-Erleben der Methode. Voraussetzung für das bestmögliche Ergebnis ist allerdings unbedingt eine professionelle Unterstützung bei der Moderation – die Dynamik des Formats und die vielen kleinen Hinweise und Anregungen, die sonst verloren gehen, machen die Investition auf jeden Fall wett.

Als Grundlage für das Entwerfen komplexer Geschäftsanwendungen hat sich dieses Vorgehen hundertfach entscheidend bewährt und ist nach meiner Einschätzung uneingeschränkt zu empfehlen.

Mein Dank gilt Tobias Goeschel für das Training, für die tollen Diskussionen über Event Storming und seine Unterstützung beim Schreiben dieses Blog Posts.

Vom EventStorming-Erfinder persönlich lernen? – Jetzt Ticket sichern!