Am 7. April 2025 war ich zum ersten mal Live mit der ersten Folge meines neuen Streams. Mein Ziel ist es, etwas DDD Know-How unter die Leute zu bringen, und Ihnen mehr Lust darauf zu machen, eines meiner DDD-Trainings zu besuchen.

Viel Spaß beim Zuschauen, seien Sie auch LIVE dabei und kommentieren Sie im Chat!

S01E01 vom 7. April 2025: Event Storming auf einer Beispieldomäne

Hier eine kurze Inhaltsangabe:

Was ist Domain Driven Design?

Domain Driven Design (DDD) ist eine Methode zur Softwareentwicklung, die 2003 von Eric Evans in seinem gleichnamigen Buch vorgestellt wurde. Bei DDD steht die Domäne - ein "Bereich von Wissen und Einfluss" - im Mittelpunkt. Gemeint ist damit der fachliche Kontext, für den eine Softwarelösung entwickelt werden soll.

Das Ziel von DDD ist es, von der fachlichen Domäne über ein gemeinsam erstelltes Modell zur Software zu gelangen. Dieses Modell dient als Abstraktion der realen Welt und enthält das wichtigste Fachwissen, das für die Entwicklung der Software relevant ist.

Warum ist eine Domäne so wichtig?

Eine Domäne bringt zwei wesentliche Elemente mit sich:

  1. Wissen: Fachexperten verfügen über umfangreiches Knowhow in ihrem Bereich. Beispielsweise verstehen Logistikexperten die komplexen Abläufe beim Transport von Waren auf Schiffen.
  2. Einflüsse: Jede Domäne unterliegt verschiedenen Einflüssen - etwa Sicherheitsanforderungen, wirtschaftliche Faktoren oder gesetzliche Regelungen.

Event Storming: Der Workshop-Einstieg in DDD

Event Storming ist eine von Alberto Brandolini entwickelte Workshop-Methode, die einen einfachen Einstieg in die Domain-Modellierung ermöglicht. Sie bringt Fachexperten und IT-Fachleute zusammen, um gemeinsam domänenrelevante Ereignisse zu identifizieren und zu verstehen.

Praktisches Beispiel: Ein betriebliches Vorschlagssystem

Als Beispieldomäne dient ein betriebliches Vorschlagssystem. Die Anforderung: Mitarbeiter sollen Verbesserungsvorschläge einreichen können, das Management soll diese bewerten und über deren Umsetzung entscheiden können.

Der Event Storming Prozess

Schritt 1: Events sammeln

Zunächst werden alle geschäftlich relevanten Ereignisse gesammelt. Für unser Vorschlagssystem könnten das sein:

  • Vorschlag eingereicht
  • Vorschlag veröffentlicht
  • Management hat Vorschlag geprüft
  • Kosten ermittelt
  • Zeitplan geprüft
  • Arbeitskraft geprüft
  • Vorschlag genehmigt
  • Vorschlag abgelehnt
  • Projekt definiert
  • Teams zum Kommentieren eingeladen
  • Umsetzung gestartet
  • Kategorie definiert
  • Vorschlag einer Kategorie zugeordnet

Wichtig: Events werden immer in der Vergangenheitsform formuliert, um eine abgeschlossene Handlung darzustellen.

Schritt 2: Pivotal Events identifizieren

Aus den gesammelten Events werden besonders wichtige Ereignisse (Pivotal Events) identifiziert, die Phasenübergänge markieren, etwa:

  • Vorschlag eingereicht
  • Kosten ermittelt
  • Vorschlag genehmigt/abgelehnt

Schritt 3: Flows definieren

Anhand der Pivotal Events werden Prozessabschnitte oder "Flows" definiert, die den Geschäftsprozess strukturieren:

  • Ideenfindung: von der Ideensammlung bis zur Einreichung eines Vorschlags
  • Engere Auswahl: von der Veröffentlichung bis zur Kostenermittlung
  • Planung: weitere Prüfungen bis zur Genehmigung/Ablehnung
  • Umsetzung: Projektdefinition und Start der Implementierung

Schritt 4: Beteiligte Personen zuordnen

Jedem Event werden beteiligte Rollen zugeordnet, z.B.:

  • Mitarbeiter (reichen Vorschläge ein)
  • Projektleiter (laden Teams ein, kategorisieren)
  • Management (prüfen Vorschläge, genehmigen)
  • Planungsabteilung (ermitteln Kosten)
  • Werksleitung (beteiligt an Genehmigungen)

Schritt 5: Systeme identifizieren

Neben den Personen werden auch beteiligte Systeme identifiziert:

  • Vorschlagssystem (zentrale Komponente)
  • Budgetierungssystem (für Kostenermittlung)

Schritt (nicht erst 6): Hotspots markieren

Während des gesamten Workshops können "Hotspots" markiert werden – Punkte, an denen es offene Fragen, Probleme oder Risiken gibt, wie etwa "Niemand weiß, wie das geht" bei der Kostenermittlung. Später können die Teilnehmer die Hotspots konzentriert besprechen und lösen.

Wie geht es weiter?

Nach dem Event Storming folgt die Aufteilung des Modells in "Bounded Contexts" – abgegrenzte Bereiche mit gemeinsamer Sprache und Verständnis. Für jeden dieser Kontexte werden dann detaillierte Prozesse modelliert, aus denen schließlich die Software entwickelt werden kann.

In der nächsten Folge sehen wir uns an, wie man auf einem solchen Event Storming Board die Bounded Contexts findet (und warum das hilfreich ist).

Fazit

Event Storming ist ein wertvoller Einstieg in Domain Driven Design, der es ermöglicht, mit geringem Aufwand ein gemeinsames Verständnis der Domäne zwischen Fachexperten und Entwicklern zu schaffen. Die visuelle, kollaborative Natur dieser Methode fördert den Dialog und hilft, komplexe Geschäftsprozesse zu durchdringen und zu strukturieren.