Einführung und Kontext

In dieser Folge von "DDD Live" setzt Matthias Bohlen seine Erklärungen zum Domain-Driven Design fort, indem er sich auf das Thema Prozessmodellierung konzentriert. Er knüpft an die vorherige Episode an, in der er über Bounded Contexts gesprochen hat, und erläutert nun, wie man innerhalb dieser Kontexte Geschäftsprozesse modellieren kann.

Als Beispiel verwendet Matthias weiterhin das "betriebliche Vorschlagswesen" - ein System, in dem Mitarbeiter Verbesserungsvorschläge einreichen können, die dann vom Management bewertet und eventuell zur Umsetzung freigegeben werden. In der vorherigen Folge hat er bereits vier Bounded Contexts identifiziert: den Vorschlagskontext, den Budgetkontext, den Plankontext und den Projektkontext.

Die Event Storming Farbgrammatik

Matthias erläutert die sogenannte "Farbgrammatik" des Event Stormings, die von Alberto Brandolini in seinem Buch "Introducing Event Storming" definiert wurde. Diese Grammatik legt fest, welche Arten von Zetteln (durch Farben codiert) in welcher Reihenfolge kombiniert werden können, um Prozesse zu modellieren:

  • Orange Zettel (Events): Repräsentieren etwas, das bereits geschehen ist
  • Blaue Zettel (Commands): Befehle an das System, die wie "Tue etwas" formuliert sind
  • Grüne Zettel (Read Models): Daten, die dem Benutzer angezeigt werden
  • Lila Zettel (Policies): Automatische Verfahren, die auf bestimmte Events reagieren
  • Gelbe Zettel (User): Repräsentieren Benutzer, die mit dem System interagieren

Der typische Ablauf eines Prozesses nach dieser Farbgrammatik ist:

  1. Der Benutzer sieht ein Read Model (Daten)
  2. Er gibt ein Command an das System
  3. Das System verarbeitet das Command und erzeugt ein Event
  4. Das Event führt zu einem aktualisierten Read Model oder löst eine Policy aus

Prozessmodellierung Schritt für Schritt

Matthias demonstriert die Prozessmodellierung anhand des Vorschlagskontexts, indem er den Prozess von "Vorschlag gefunden" bis "Vorschlag eingereicht" modelliert. Er beginnt mit der Definition eines "Trigger Events" (Vorschlag gefunden) und eines "Outcome Events" (Vorschlag eingereicht) und zeigt dann, wie man den Weg zwischen diesen beiden Punkten modelliert.

Der von ihm modellierte Prozess umfasst:

  1. "Vorschlag gefunden" (Trigger-Event)
  2. "Vorschlagsmenge" (Read Model, das die Mitarbeiter im Kopf haben)
  3. Eine Mitarbeiterin gibt das Command "Füge Vorschlag hinzu"
  4. Das System verarbeitet dieses Command und erzeugt das Event "Vorschlag hinzugefügt"
  5. Das System zeigt eine aktualisierte "Vorschlagsmenge" an (Read Model)
  6. Die Mitarbeiterin gibt das Command "Lege neue Kategorie an"
  7. Das System erzeugt das Event "Kategorie angelegt"
  8. Das System zeigt die Liste der Kategorien an (Read Model)
  9. Die Mitarbeiterin gibt das Command "Ordne Vorschlag Kategorie ein"
  10. Das System erzeugt das Event "Vorschlag eingeordnet"
  11. Das System zeigt "Kategorisierte Vorschläge" an (Read Model)
  12. Die Mitarbeiterin gibt das Command "Reiche Vorschlag ein"
  13. Das System erzeugt das Event "Vorschlag eingereicht" (Outcome-Event)

Matthias ergänzt auch eine automatische Reaktion auf das "Vorschlag eingereicht"-Event, indem er eine Policy hinzufügt, die das Management per E-Mail benachrichtigt.

Der Wert von Event Storming in Workshops

Matthias betont, dass in einem echten Workshop mit Stakeholdern dieser Prozess nicht so geradlinig verlaufen würde. Stattdessen würden viele Diskussionen stattfinden, bei denen die Teilnehmer über die Reihenfolge der Schritte, die erforderlichen Daten und andere Details diskutieren würden.

Er erwähnt auch, dass man "Hotspots" verwenden kann, um Fragen oder Probleme zu markieren, die später geklärt werden müssen. Dies ist besonders nützlich in großen Workshopgruppen, um den Prozess nicht zu unterbrechen.

Ausblick

Zum Abschluss der Session gibt Matthias einen Ausblick auf die nächste Folge, in der er auf der Designebene fortfahren will. Dort wird er zeigen, wie man die identifizierten Prozesse und Verantwortlichkeiten auf konkrete Softwarebausteine abbilden kann, was einen weiteren wichtigen Schritt im Domain-Driven Design darstellt.

Matthias betont auch, dass in einem echten Projekt die Teams für die verschiedenen Bounded Contexts jeweils ihre eigenen Prozessmodelle erstellen würden und sich dann über die Kontextgrenzen hinweg abstimmen müssten, welche Events und Daten ausgetauscht werden sollen.

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

, Domain-Driven Design