What needs to be finished first
An overview of domain events and pivotal events exists so Event Modeling can focus on a concrete scenario.
At least one spoken scenario for the chosen use case exists that surfaces user intent and handoffs.
What needs to be ready before start
Long board (at least 4 m or digital with zoom), horizontal swimlanes (UI/wireframes at top, commands and events middle, read models and state at bottom); orange stickies for events, blue for commands, light blue for read models, yellow for user intent or triggers; markers.
One facilitator with Event Modeling experience; one to two domain experts; two to four engineers; optional UX representative for wireframes.
Concrete scenario ("From cart to paid order"); pivotal events from EventStorming; existing UI mockups or screens; known read models or reports.
2-6 h
Set up board with time axis left to right. Mark three swimlanes (UI/wireframes, Behavior/commands+events, Data/read models). Attach pivotal events as anchors in the middle lane.
The one question this method answers
Which events, commands, and read models cover the chosen user flow end-to-end, and how can we slice implementation from this?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Wireframes or UI sketches | 20-40 min | Attach UI step sketches or wireframes of the scenario in the top swimlane. One image per step, arranged chronologically left to right. | Wireframes can be pencil sketches; details do not matter. What matters is which information the user sees when, and which action they trigger. |
2Phase 2: Commands from user intent | 30-45 min | Place one command (blue) in the middle lane directly under each UI action. Use imperative command names ("PlaceOrder", "CancelReservation"). | If a UI element does not trigger a command, it is read-only. If a command has no UI trigger, it is system-triggered (scheduler, external event). |
3Phase 3: Events following commands | 30-45 min | Place one or more events (orange) to the right of each command. Event names should be past tense ("OrderPlaced", "ReservationCancelled"). Draw explicit command → event relations. | A command can create multiple events or fail (failure events). Model failure events explicitly, do not omit them implicitly. |
4Phase 4: Read models and state | 30-45 min | Bottom lane: identify which data is shown on each UI screen. Derive read models (light blue) and connect them to events that update them. | Read models derive from events, not from tables. If a read model cannot be derived from events, either an event is missing or the read model is cut incorrectly. |
5Phase 5: Slices and implementation plan | 30-45 min | Create vertical slices through the board: one slice equals one user step with command, events, read model update, and UI display. Estimate and prioritize each slice. | Vertical slicing enables incremental delivery. Teams that cut horizontally (all commands, then all events) deliver no user value until the end. |
What comes out at the end
Event Modeling board (photo or digital export) plus structured markdown with a slice list containing commands, events, read models, and UI references. Link to bounded context canvases and ADRs.
One board entry with date per scenario. On model changes (new slices, changed events), create a new version. Keep prior versions to preserve model evolution.
Compact working template for Event Modeling with context, input, output artifacts, and next step.
Models system behavior through Events, Commands, Views, and Policies along a scenario.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Scenario: From cart to shipping confirmation
Slice 1: Show cart
Slice 2: Start checkout
Slice 3: Authorize payment
Slice 4: Submit order
Slice 5: Receive shipping confirmation (asynchronous)
Implementation order: Slice 4 first (core value), then 2+3, then 1+5.
Recognize symptoms and steer against them
Some stickies use imperative form and some use past tense, colors get misused.
Enforce color and naming discipline from the start. Facilitator corrects immediately. Command = intent (CamelCase imperative), event = result (CamelCase past tense).
Every command only has happy-path events, and error cases are not modeled.
Ask explicitly for each command: what can go wrong? Model failure events (PaymentDeclined, ReservationFailed). Otherwise code behavior is incomplete.
Read models are drawn from current database tables instead of being derived from events.
Check strictly: can this read model be reproduced from the events in the lane? If not, events are missing or read model is cut incorrectly.
Implementation is planned in phases: all commands, then all events, then all read models.
Slice vertically. One slice should contain command + events + read model + UI. This creates end-to-end value for each slice.
A PSP or carrier webhook is not modeled and appears later in code unexpectedly.
Model external triggers explicitly as yellow stickies (user intent or system trigger). Otherwise integration remains hidden and surprises the team later.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.