Was vorher fertig sein muss
Eine Übersicht der Domain Events und Pivotal Events liegt vor, sodass das Event Modeling sich auf ein konkretes Szenario fokussieren kann.
Mindestens eine erzählte Story für das gewählte Szenario existiert, die User Intent und Übergaben sichtbar gemacht hat.
Was vor Start vorliegen muss
Langes Board (mindestens 4 m oder digital mit Zoom), horizontale Swimlanes (UI/Wireframes oben, Commands und Events Mitte, Read Models und State unten); orange Stickies für Events, blau für Commands, hellblau für Read Models, gelb für User Intent oder Trigger; Marker.
Ein Facilitator mit Event-Modeling-Erfahrung; ein bis zwei Domain-Experten; zwei bis vier Engineers; optional ein UX-Vertreter für Wireframes.
Konkretes Szenario („Vom Warenkorb zur bezahlten Bestellung“); Pivotal Events aus EventStorming; bestehende UI-Skizzen oder Screens; bekannte Read Models oder Reports.
2-6 h
Board mit Zeitachse links nach rechts. Drei Swimlanes markieren (UI/Wireframes, Behavior/Commands+Events, Data/Read Models). Pivotal Events vorab in die mittlere Spur kleben als Ankerpunkte.
Die eine Frage, die diese Methode beantwortet
Welche Events, Commands und Read Models bilden den gewählten User-Flow End-to-End ab und welche Slices lassen sich daraus zur Implementierung schneiden?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Wireframes oder UI-Skizzen | 20-40 min | In der oberen Swimlane Wireframes oder Skizzen der UI-Schritte des Szenarios kleben. Pro Schritt ein Bild, links nach rechts chronologisch. | Wireframes können Bleistift-Skizzen sein, Details egal. Was zählt: welche Information sieht der Nutzer wann, welche Aktion löst er aus. |
2Phase 2: Commands aus User Intent | 30-45 min | Pro UI-Aktion einen Command (blau) in die mittlere Spur kleben, direkt unter den Wireframe. Command-Name als Imperativ („PlaceOrder“, „CancelReservation“). | Wenn ein UI-Element keinen Command auslöst, ist es Read-only (Anzeige). Wenn ein Command keinen UI-Trigger hat, ist er System-getriggert (Scheduler, externes Event). |
3Phase 3: Events als Folge der Commands | 30-45 min | Pro Command einen oder mehrere Events (orange) rechts daneben. Event-Name als Vergangenheit („OrderPlaced“, „ReservationCancelled“). Beziehung Command → Event explizit zeichnen. | Ein Command kann mehrere Events erzeugen oder fehlschlagen (Failure Events). Failure Events explizit modellieren, nicht implizit weglassen. |
4Phase 4: Read Models und State | 30-45 min | Untere Spur: pro UI-Bildschirm welche Daten gezeigt werden. Daraus Read Models (hellblau) ableiten und mit den Events verbinden, die sie aktualisieren. | Read Model entsteht aus Events, nicht aus Tabellen. Wenn ein Read Model nicht aus den Events ableitbar ist, fehlt entweder ein Event oder das Read Model ist falsch geschnitten. |
5Phase 5: Slices und Implementierungsplan | 30-45 min | Vertikale Slices durchs Board: ein Slice = ein User-Schritt mit Command, Events, Read-Model-Update, UI-Anzeige. Pro Slice Aufwand schätzen und priorisieren. | Vertikale Slices ermöglichen schrittweise Auslieferung. Wer horizontal schneidet (erst alle Commands, dann alle Events), liefert keinen User Value bis ganz am Ende. |
Was am Ende rauskommt
Event-Modeling-Board (Foto oder digitaler Export) plus strukturiertes Markdown mit Liste der Slices, pro Slice Commands, Events, Read Models und UI-Bezug. Verlinkt zu Bounded Context Canvases und ADRs.
Pro Szenario eigener Board-Eintrag mit Datum. Bei Änderungen am Modell (neue Slices, geänderte Events) neue Version. Alte Versionen behalten zur Historie der Modell-Evolution.
Kompakte Arbeitsvorlage für Event Modeling mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Event Modeling Arbeitsvorlage
## Ziel
Modelliert Systemverhalten über Events, Commands, Views und Policies entlang eines Szenarios.
## 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 Model:
- UI Flow:
- Commands:
- Read Models:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Event Model — Checkout Flow (v1, 2026-05-18)
**Szenario**: Vom Warenkorb zur Versandbestätigung
**Slice 1: Warenkorb anzeigen**
- UI: CartView (zeigt Items, Summe, Versandkostenschätzung)
- Read Model: CartReadModel (aus ItemAddedToCart, ItemRemovedFromCart, CartCleared)
- Commands: keine (Read-only)
**Slice 2: Checkout starten**
- UI: CheckoutAddressForm
- Command: StartCheckout
- Events: CheckoutStarted, AddressRequested
- Read Model: CheckoutSessionReadModel
**Slice 3: Zahlung autorisieren**
- UI: PaymentMethodPicker → PaymentConfirmation
- Command: AuthorizePayment
- Events: PaymentAuthorized | PaymentDeclined
- External: PSP-Webhook → PaymentCaptured
- Read Model: PaymentStatusReadModel
**Slice 4: Bestellung absenden**
- UI: OrderConfirmation
- Command: PlaceOrder
- Events: OrderPlaced, ReservationConfirmed, EmailQueued
- Read Model: OrderSummaryReadModel
**Slice 5: Versandbestätigung empfangen (asynchron)**
- Trigger: CarrierShippedWebhook (extern)
- Command: RecordShipment
- Events: OrderShipped
- Read Model: OrderStatusReadModel
**Implementierungsreihenfolge**: Slice 4 zuerst (Kern-Wert), dann 2+3, dann 1+5.Symptome erkennen, gegensteuern
Auf Stickies stehen mal Imperative, mal Vergangenheitsform, Farben werden falsch benutzt.
Farb- und Namens-Disziplin von Anfang an. Facilitator korrigiert sofort. Command = Absicht (CamelCase Imperativ), Event = Folge (CamelCase Vergangenheit).
Jeder Command erzeugt nur Happy-Path-Events, Fehlerfälle sind nicht modelliert.
Pro Command explizit fragen: was kann schief gehen? Failure-Event modellieren (PaymentDeclined, ReservationFailed). Sonst fehlt das Handling im Code.
Read Models entstehen, indem aktuelle DB-Tabellen abgemalt werden, nicht aus Events abgeleitet.
Strikt prüfen: kann das Read Model aus den Events der Spur reproduziert werden? Wenn nein, fehlen Events oder Read Model ist falsch geschnitten.
Implementierung wird in Phasen geplant: zuerst alle Commands, dann alle Events, dann alle Read Models.
Vertikal schneiden. Pro Slice Command + Events + Read Model + UI. So entsteht funktionierender End-to-End-Wert nach jedem Slice.
Webhook von PSP oder Carrier wird nicht modelliert, taucht plötzlich im Code auf.
Externe Trigger explizit auf das Board als gelbe Stickies (User Intent oder System Trigger). Sonst geht die Integration unter und überrascht das Team später.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.