Event Storming – der erste Schritt zu DDD?

„In any Event Storming session of all different kinds,
everyone knows what everyone else knows“
- Dan North

Event Storming ist eine Methode zum Erkennen und Konkretisieren der Informationen über den Geschäftsbereich, in dem Software erstellt wird.

Handel, Telekommunikation, Finanzen, Bildung, Recht und Medizin – das sind einige Geschäftsbereiche, mit denen sich Programmierer und technische Experten in ihrer täglichen Arbeit beschäftigen. Darüber hinaus erfordert ein Projektwechsel das Wissen über eine neue Fachdomäne.

Wie also erhält man die dafür nötigen Informationen, um hochwertige Software für eine Domäne zu entwickeln, die wir oft nicht vollständig kennen? Eine Antwort auf die Frage kann und sollte Event Storming sein, ebenso wie das zugehörige Domain-Driven Design (DDD).

Dieser Artikel stellt grundlegende Informationen über das Event Storming vor, seine Vorteile und seinen Verlauf Schritt für Schritt anhand des gewonnenen Wissens aus einem Workshop, der in der FIS-SST vom R&D-Team durchgeführt wurde.

Event Storming – Grundlagen

Wer ist beteiligt?

Es ist in der Regel ein mehrstündiger Workshop, an dem folgende Personengruppen beteiligt sind:

  • IT-Experten, wie z. B. Programmierer, Analytiker oder der Product Owner (PO)
  • Fachexperten des Auftragsgebers
  • und ein Moderator (Facilitator) - eine Person, welche mit der Event Storming Technik vertraut ist und dabei für einen effizienten und korrekten Ablauf des Workshops sorgt.

Worum geht es?

Die Form des Workshops selbst scheint recht einfach zu sein. Wir haben eine große Tafel oder eine Wand und dazu viele bunte Post-its zur Verfügung.

Jeder Teilnehmer identifiziert fachliche Ereignisse (Domain Events), die im Geschäftsprozess auftreten, z. B. „Benutzerkonto erstellt“, „Ware bestellt“ oder „Rechnung erstellt“. Diese Ereignisse werden auf die Post-its geschrieben und an der Tafel platziert.


An den oben genannten beispielhaften Ereignissen sieht man, dass es sich um allgemein verständliche Begriffe handelt. Während des Event Stormings versuchen wir kein Fachvokabular und keine streng spezialisierte Sprache zu verwenden. Ziel ist es, dass jeder jeden versteht und die verwendeten Begriffe eindeutig und für alle Teilnehmer verständlich sind.


Die obigen Domain-Events sind der Ausgangspunkt für weitere Fragen. Was muss passieren, damit das Ereignis „Benutzerkonto erstellt“ stattfinden kann? Die Information muss an die Software übermittelt werden, was durch den Befehl („Command“), z. B. „Erstell Benutzerkonto“, signalisiert wird. Aber wer oder was ist die Quelle eines solchen Befehls? Erstellt der Benutzer durch die Registrierung ein eigenes Konto? Wird das Benutzerkonto basierend auf den vom externen System empfangen Informationen automatisch generiert? Und hier kommt ein weiteres, während des Workshops identifizierte Element – der Auslöser („Actor“) welcher den Befehl aufruft.


Auch die Regeln für Befehle und Auslöser müssen irgendwie aufgeschrieben werden. Natürlich in Form von weiteren Post-its, die nacheinander an der Tafel, die immer voller wird, angehängt werden. In einer späteren Phase des Workshops werden die fachverwandten Elemente zusammen gruppiert – es bilden sich die sogenannten Aggregate („Aggregates“).

Warum das alles?

Alle oben genannten Elemente – Domänenereignisse, Befehle, Auslöser und die identifizierten Aggregate – vermitteln den Workshop-Teilnehmern ein klares Verständnis und die Funktionsweise der modellierten Software. Die beteiligten Personen identifizieren selbstständig Prozesse, welche zu deren Fachdomäne gehören und durch die Software unterstützt werden. Nach diesem Workshop haben Fachexperten ein klareres Bild davon, wie das Produkt funktionieren soll. Die IT-Experten können das gewonnene Fachwissen und die identifizierten Aggregate unter Verwendung von DDD-Prinzipien in den Code übertragen.

Was für Vorteile bietet uns Event Storming an?

Verständnis der Domäne

Beim Event Storming findet ein Wissensaustausch zwischen IT-Experten und Fachexperten statt. Es wird nicht über die Datenbanken, Frameworks oder relationalen Objekt-Mappings gesprochen. Stattdessen verwenden alle Teilnehmer Domänenbegriffe. Die IT-Experten lernen die Fachdomäne kennen und die Fachexperten vertiefen die Funktionsweise der Software.

Gemeinsame Sprache

Event Storming stellt eine Wissensaustauschplattform zwischen dem Business und der Entwicklung, um die verwendeten Konzepte zu vereinheitlichen dar. Eine gemeinsame und einheitliche Sprache ist ein großer Schritt in Richtung eines erfolgreichen Projekts, der auf Domain-Driven Design basiert.

Handlungsgeschwindigkeit

Bei neuen, gerade beginnenden Projekten ist Event Storming eine Alternative zu längeren Vorplanungsprozessen. Ein Treffen in einem mehrstündigen Workshop mit verschiedenen Personen, die in einem solchen frühen Stadium der Entwicklung an einem bestimmten Produkt beteiligt sind, kann vorteilhafter sein, als die Findung von Produktmerkmalen erst in der Entwicklungsphase.

Wissensverbreitung

Event Storming fördert Wissensaustausch – sowohl innerhalb als auch zwischen den Teams. Eine solche Wissensverteilung zwischen verschiedenen, an der Softwareentwicklung beteiligt Personen, verhindert die Entstehung von sogenannten Wissenssilos. Dies gibt Fachleuten die Möglichkeit zu lernen und sich stärker in das Projekt einzubringen. Zusätzlich gewährleistet es einen reibungslosen Arbeitsablauf des Projekts bei Personalwechsel.

Qualitätssicherung

Event Storming bedeutet nicht nur ein besseres Verständnis der Domäne, sondern auch eine eingehende Analyse der Abhängigkeiten zwischen den verschiedenen Software-Funktionen. Die volle Verinnerlichung der fachlichen Prozesse, die in dem hergestellten Produkt ablaufen, ist einer der Faktoren, welcher zur Lieferung eines qualitativ hochwertigen Produktes führt.

Identifizierung von Problemen

Langfristige Projekte können auch durch die Verwendung von Event Storming, als Problemanalyse-Tool profitieren, um z. B. die Engpassfaktoren zu erkennen und zu beseitigen.

Integration

Event Storming lebt von der Kommunikation und der Beteiligung von vielen Parteien, dadurch bietet es dem Team die Möglichkeit, durch das gemeinsame Lernen, auf dessen beschleunigte Integration. Für Menschen, die mit der Arbeit in einem Projekt beginnen, stellt die Teilnahme an solchen Workshops eine perfekte Einarbeitungsmöglichkeit dar.

Event Storming- Schritt für Schritt

In der FIS-SST haben wir, als Teil des R&D-Teams, einen eigenen Event-Storming Workshop durchgeführt. Wir haben das Wissen zur Thema Event Storming, als auch bewährte Verfahren zur Erstellung von Software im Rahmen von Domain-Driven Design vertieft. Nach einer Reihe langer Artikel, haben wir uns mit dem Buch des Event Storming Erfinders – Alberto Brandolini – befasst. Zusätzlich schauten wir uns zu dem Thema mehrere Präsentationen aus verschiedenen Entwicklerkonferenzen an. Jetzt waren wir bereit und machten uns an die Arbeit! Im weiteren Verlauf des Artikels teilen wir mit Ihnen unser Wissen und unsere Erfahrungen mit.

Wie man einen Workshop startet?

Wir brauchten eine große Wand, elektrostatisches Papier und farbige elektrostatische Post-its. Nach den Vorgaben des Event Stormings müssen alle Teilnehmer des Workshops stehen. So haben wir unsere Stühle an den Schreibtischen gelassen. Unsere Aufgabe war es, eine neue Einzelhandelsanwendung zu modellieren, mit deren Entwicklung in Kürze begonnen werden sollte.

Schritt 1: Die Domain-Events

Bild 1: Ein Domain-Event (in Orange) mit zusätzlichen Informationen (in Gelb)

Das Herz des Workshops und der Ausgangspunkt für das erstellte Geschäftsmodell waren die Domain-Events. Wir mussten die Aktionen definieren, die während des Betriebs der modellierten Software stattfinden sollten.


Welche Vorgaben geben uns die Erfinder von Event Storming in Bezug auf Domänenereignisse an? Ereignisse sollen aus Sicht von Fachexperten wichtig sein und in der Vergangenheitsform ausgedrückt werden.


Jeder von uns schlug daher Beispiele für entsprechende Ereignisse vor. Wir haben sie kurz besprochen und dann klebte jeder einen orangenen Post-it mit dem aufgeschriebenen Ereignis an die Wand. Wir haben zum Beispiel Ereignisse wie „Benutzer autorisiert“, „externe Bestellung eingegangen“ oder „Saldo geändert“ erstellt. Die Ereignisse haben wir in einer zeitlichen Reihenfolge ihres Auftretens im Prozess an der Wand platziert. Am Ende dieses Schrittes haben wir eine „Zeitachse” unseres Programms erhalten. Anschließend führten wir eine Rückwärtsprüfung durch – von dem letzten bis zum ersten Ereignis. Wir überprüften, ob alle wichtigen Domänen-Ereignisse berücksichtigt wurden. Es ist an der Zeit die Befehle hinzuzufügen.

Schritt 2: Die Befehle

Bild 2: Ein Befehl (blau) ist einem Ereignis zugeordnet

Wir überlegten, welche Aktionen zum Auftreten der in den vorangegangenen Schritten identifizierten Ereignisse führen. Infolgedessen haben wir den meisten Ereignissen blaue Post-its mit Befehlen zugeordnet. Wir stellten fest, dass die Befehle in vielen Fällen sehr ähnlich zu den Ereignissen klingen. So wurde das Ereignis „Benutzer autorisiert“, mit dem Befehl „Autorisier Benutzer“ verbunden. Es war uns bewusst, dass während der Entwicklung die erstellten Befehle als Methoden implementiert werden sollten. Aber es war noch nicht die Zeit, um über den Code nachzudenken. Wir wussten noch nicht, wer oder was für den Aufruf von Befehlen verantwortlich ist. Dies galt es jetzt zu erörtern.

Schritt 3: Der Auslöser

Bild 3: Ein Befehl (blau) mit dem Auslöser, hier mit dem Benutzer markiert

Im einfachsten Fall war von vornherein klar, dass der Auslöser des Befehls ein Benutzer ist. Somit haben wir den Befehl sofort entsprechend markiert. Auf der anderen Seite sind einige Befehle zum Ausgangspunkt für viele Fragen und Diskussionen geworden. Zum Beispiel „Wie soll die von uns entwickelte Anwendung überhaupt funktionieren?“. Wir haben uns gefragt, wie wir die Möglichkeit einer Bestellung durch den Benutzer blockieren können. Wird die Blockade durch ein anderes Ereignis ausgelöst oder einen bestimmtes Zeitintervall?

Hier sollte man die Vorgaben von Event Storming auf jeden Fall beachten. Es gibt viele verschiedene Ereignisauslöser. Es kann durch einen Befehl, ein externes System, einen Zeitablauf oder sogar ein anderes Domänenereignis ausgelöst werden.
 

Nach der Beantwortung vieler unterschiedlicher Fragen war unsere Event-Zeitachse fertig. Wir konnten uns in die Richtung von DDD wenden und die Aggregate bestimmen.

Schritt 4: Die Aggregate

Bild 4: Ein Aggregat (grün), mit daneben gruppierten Ereignissen und Kommandos.

Im nächsten Schritt unseres Workshops mussten wir unsere sorgfältig erstellte Event-Zeitachse neu sortieren! Post-its, mit den Ereignissen, zusammenhängende

Kommandos und die Auslöser wurden gruppiert und zu Aggregaten zusammengefasst.
Einige Aggregate konnten mit Leichtigkeit identifiziert werden – wie zum Beispiel „Benutzer“. Neue grüne Post-its fanden ihren Weg an die Wand. Wir gruppierten alle benutzerspezifischen Domänenelemente um dieses Post-it herum.


Einige Aggregate waren jedoch schwerer zu identifizieren. So wurde beispielsweise das neue Aggregat „Abrechnung“ mit einer großen Anzahl an zusammenhängenden Post-its in zwei getrennte Aggregate – „Benutzerabrechnung“ und „Auftragsabrechnung“ aufgeteilt.


Vor uns war der letzte Schritt. Wir mussten bestimmen, welche Aggregate miteinander verbunden sind, um sie zu einem so genannten „Bounded Context“ zusammenzufassen.

Schritt 5: Der Bounded Context

Domain-Driven Design weist darauf hin, dass die Grenzen einer gemeinsamen Sprache („Ubiquitous Language“) ein Marker für die Grenzen von Bounded Context sind.

Wie kann man dies in die Praxis umsetzen? Nehmen wir als Beispiel die Domäne des Einzelhandels. Fachexperten, die am Verkauf beteiligt sind, weisen dem Produkt eine Reihe von Merkmalen zu. Im Bereich der Lagerung und des Versands werden den Fachexperten ganz andere Produkteigenschaften interessieren als im Verkauf. Dadurch erhalten IT-Experten und insbesondere Entwicklungsteams zwei unterschiedliche Produktdefinitionen. Für den Verkauf des Produkts sind z. B. der Preis und seine Preisentwicklung wichtig. Diese Merkmale können aus der Sicht des Lagers und des Versands völlig unbedeutend sein. Zu den wichtigen Eigenschaften gehört hier z. B. die Produktabmessung und die Zuordnung zu einem bestimmten Lager. Auf der Basis von oben erwähnten Punkten werden im Code zwei separate Modelle entstehen – z. B. SaleItem und InventoryItem. Obwohl beide Produkte sind, gehört SaleItem und InventoryItem zu zwei verschiedenen Kontexten.

Wie haben wir uns während unseres Workshops mit den Kontexten auseinandergesetzt? In Gegensatz zu den möglichen ersten Assoziationen waren die zuvor genannte „Abrechnung des Nutzers“ und „Abwicklung der Bestellung“ nicht im gleichen Kontext. Wir haben die „Benutzerabrechnung“ dem gleichen Kontext zugeordnet wie den „Benutzer“ selbst, analogisch zum oberen Items-Beispiel.

 
 
Bild 5: Die Wand am Ende des Workshops

Ist das alles?

Definitiv nicht! Der Event Storming Prozess kann viel komplexer sein und viel mehr Schritte beinhalten, je nach der Projektanforderung. Es gibt nicht die eine, wahre Interpretation von Event Storming. Das Wichtigste ist es, zu welchen Ergebnissen führt es und wann kann es nützlich sein.

Mit Event Storming kann man – genau wie wir – neue Software modellieren. Es kann auch für Altsysteme angewendet werden. Event Storming kann auch bei sehr großen und komplexen Applikationen äußerst nützlich sein. Die Fokussierung auf der Fachdomäne kann in vielen Projekt den Weg zur Einführung von Domain-Driven Design ebnen.

Durch Event Storming ist es uns gelungen, nicht nur einen Ausgangspunkt für die Programmierarbeiten an unserer neuen Anwendung zu schaffen. Wir haben dafür gesorgt, dass alle Projektteilnehmer den Umfang, die Funktionsweise und die Funktionalitäten des Systems gleichermaßen verstehen. Dem Satz von Dan North, mit dem wir den Artikel begonnen haben „in any Event Storming session of all different kinds, everyone knows what everyone else knows“ können wir nur zustimmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.