Eine Liste der Domainexperten pro Geschäftsbereich liegt vor, sodass die richtigen Personen den ganzen Flow bezeugen können.
EventStorming
Vorbedingung
Was vorher fertig sein muss
Bei sehr komplexen Domains liegt mindestens eine erzählte Beispielgeschichte mit Akteuren und Artefakten vor, an der sich die Eventkette anlagern kann.
Vorbereitung
Was vor Start vorliegen muss
Lange Wand oder digitales Board mit mindestens 8 m horizontaler Fläche; orange Haftnotizen (Events), blau (Commands), gelb (Actors), pink (Hot Spots), lila (Policies), grün (Read Models); Marker; Kamera für Snapshots; Parkplatz-Fläche.
Ein Facilitator mit EventStorming-Erfahrung; drei bis sechs Domainexperten aus Business; zwei bis vier Engineers oder Architekten; ein Scribe für Hot Spots und offene Fragen.
Klar abgegrenzter Business Flow (z. B. „vom Auftragseingang bis zur Auslieferung“); Glossar bekannter Fachbegriffe; bestehende Prozessdokumentation als Backup, nicht als Vorlage.
2-8 h
Wand mit Zeitachse markieren (links Start, rechts Ende). Farben-Legende sichtbar. Regel ansagen: Events sind Vergangenheitsform und Business-relevant. Telefone weg, keine Laptops außer für den Scribe.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche Geschäftsereignisse, Auslöser und Grenzen prägen den Flow, und wo entstehen Reibung, Risiko oder Lernbedarf?
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Chaotic Storming | 30-60 min | Alle Teilnehmer schreiben Domain Events (orange, Vergangenheitsform) parallel und kleben sie grob chronologisch an die Wand. Kein Sortieren, keine Diskussion. | Erwartet werden 80-300 Events. Wenn nach 20 min nur 30 Events da sind, fehlt Domainwissen oder die Frage ist zu eng. Niemand korrigiert in dieser Phase. |
2Phase 2: Timeline Enforcement | 30-45 min | Events chronologisch ordnen, Duplikate konsolidieren, Lücken markieren. Pivotal Events (Wendepunkte) hervorheben, etwa durch Verschiebung nach oben. | Streit über Reihenfolge ist Gold, nicht Störung. Wenn die Gruppe sich nicht einig wird, beide Varianten kleben und als Hot Spot markieren. |
3Phase 3: Commands, Actors, Policies | 45-90 min | Vor jedes Event den auslösenden Command (blau) und den Actor (gelb) kleben. Automatische Folgereaktionen als Policies (lila) markieren. Read Models (grün) ergänzen, wo Entscheidungen Daten brauchen. | Wenn vor einem Event kein Command passt, ist es entweder externer Trigger (System, Zeit) oder eine Lücke. Beides explizit markieren. |
4Phase 4: Hot Spots und Boundaries | 30-45 min | Pink für jede Reibungsstelle, Risiko, Unklarheit oder Konflikt. Anschließend Boundaries (gestrichelte Linien) für Bounded Contexts oder organisatorische Grenzen ziehen. | Hot Spots sind das wertvollste Ergebnis, nicht ein Mangel. Wenn keiner entsteht, fragt der Facilitator gezielt nach Workarounds, Eskalationen und Sonderfällen. |
5Phase 5: Followups und Ableitungen | 20-30 min | Snapshot der Wand fotografieren. Pro Hot Spot Owner und nächste Aktion benennen. Glossar-Begriffe aus Events ableiten und in Ubiquitous Language aufnehmen. | Ohne benannte Followups verpufft die Energie. Mindestens drei Hot Spots brauchen Owner und Datum vor Workshop-Ende. |
Artefakt
Was am Ende rauskommt
Foto-Dokumentation der Wand pro Phase plus strukturiertes Markdown mit Event-Timeline (linear gelistet), Hot-Spot-Liste mit Owner und Datum, Bounded-Context-Skizze und Glossar der Domain-Begriffe.
- Physische Wand mit Haftnotizen und Foto-Export
- Miro mit EventStorming-Template
- FigJam mit eigenem Farbsystem
- EventCatalog (eventcatalog.dev) für persistente Doku
Pro Workshop einen Ordner mit Datum, Teilnehmer-Liste und Phasen-Snapshots. Bei Folge-Workshops nicht überschreiben, sondern neue Version anlegen und Delta zur Vorversion separat dokumentieren.
EventStorming Arbeitsvorlage
Kompakte Arbeitsvorlage für EventStorming mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# EventStorming Arbeitsvorlage
## Ziel
Schnelle, visuelle Domain-Erkundung über Business Events, Commands, Policies und Actors auf einer Zeitachse.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Event Timeline:
- Ubiquitous Language:
- Boundaries:
- Open Questions:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Beispielausgabe
Konkret gefülltes Szenario
## EventStorming — Order Fulfillment (Big Picture, 2026-05-18)
**Teilnehmer**: 4 Fachexperten (Sales, Warehouse, Shipping, Customer Service), 3 Engineers, 1 Architekt.
**Pivotal Events**: OrderPlaced, PaymentAuthorized, OrderShipped, OrderDelivered.
**Timeline-Auszug** (151 Events insgesamt):
1. CartCreated (Actor: Customer, Command: AddItem)
2. OrderPlaced (Actor: Customer, Command: PlaceOrder, Policy: ReservierungAuslösen)
3. PaymentAuthorized (External Trigger: PSP Webhook)
4. ReservationConfirmed (Read Model: StockAvailability)
5. ...
**Hot Spots**:
- Pink #1: PaymentAuthorized kommt manchmal vor OrderConfirmed an, Race Condition. Owner: @lisa, Spike bis 30.05.
- Pink #2: ManualOverrideShipped wird in 12% der Fälle genutzt, Prozess undokumentiert. Owner: @ben.
- Pink #3: ReturnInitiated hat zwei Pfade je nach Channel, Logik unklar. Owner: @anna.
**Bounded Contexts (Vorschlag)**: Ordering, Payment, Inventory, Shipping, Returns. Schnittstelle Ordering ↔ Payment ist der heißeste Konflikt.Stolperfallen
Symptome erkennen, gegensteuern
Events als Substantive statt Verben in Vergangenheit
Auf den Notizen steht „Bestellung“ oder „Versand“ statt „BestellungAufgegeben“ oder „VersandGestartet“.
Vor Phase 1 ein Beispiel an die Wand kleben. Wenn falsche Form auftaucht, sofort korrigieren, nicht warten. Falsche Notation breitet sich schnell aus.
Lösungsdiskussion in Phase 1 oder 2
Gespräch dreht sich um „wie würden wir das bauen“, statt was passiert.
Parking-Lot für Lösungsideen sichtbar an der Wand. Facilitator unterbricht sofort und parkt das Thema. Phase 5 bringt es zurück, wenn relevant.
Workshop ohne Domainexperten
Nur Engineers anwesend, alle Events sind technisch (DatabaseUpdated, MessagePublished).
Workshop abbrechen oder vertagen. EventStorming ohne Business-Stimmen erzeugt ein Daten-Modell, kein Domain-Modell.
Wand zu klein
Events überlappen, Reihenfolge wird unleserlich, neue Notizen drängen alte hinaus.
Minimum 8 m planen. Falls nicht möglich, Flow in zwei Workshops aufteilen (z. B. Sales-Seite und Fulfillment-Seite). Digital: hineinzoomen geht, aber Übersicht leidet.
Hot Spots ohne Followup
Pink-Notizen kleben überall, aber keine hat Owner oder Datum.
Letzte 20 min strikt für Followup-Zuweisung reservieren. Workshop endet nicht, bevor mindestens drei Hot Spots Owner und Frist haben.
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.