Event Storming formats
Big Picture covers the wider domain and reveals major flows, external systems, organizational boundaries, and hotspots. Process Level explores one business process in detail: commands, events, decisions, exceptions, and participants. Design Level moves closer to a software model by identifying Aggregates, Policies, Sagas, and read models.
Do not begin with class-level design. Reconstruct the business story first, then choose the level of detail that answers the current question.
- Big Picture — the domain-wide story
- Process Level — one process and its variants
- Design Level — decisions, Aggregates, and reactions
Model elements and their meaning
A Domain Event is a business-significant fact in past tense: OrderPlaced, PaymentDeclined, TicketEscalated. A Command expresses an intention to change the system: PlaceOrder, CapturePayment, EscalateTicket. An Actor initiates intent, while a Policy describes an automatic reaction to a fact.
A Read Model shows information needed to make a decision. An External System marks a participant outside the modeled responsibility. A Hotspot captures a question, conflict, or unknown that must not silently become an architectural assumption.
Running a session
Invite people who understand different parts of the process: domain experts, developers, support, operations, and product ownership. Begin with individual event generation so the most confident participant does not define the whole model. Arrange events in time, explore alternative branches, and only then add causes and reactions.
A facilitator should not impose a prepared model. Their job is to clarify meaning, surface conflicting definitions, and keep the conversation grounded in real business behavior. Give the session a concrete goal and assign owners and next actions to unresolved questions.
Timeline, branches, and failure
A business process is rarely one happy path. Include payment rejection, unavailable stock, customer cancellation, expired waits, and human intervention. Alternative paths reveal important invariants, compensations, and observability needs.
Distinguish business ordering from technical message delivery. Event Storming describes what must happen and why; queue guarantees, retries, and transaction mechanics are designed later.
Discovering context boundaries
Mark places where language, decision ownership, rate of change, or source of truth changes. When one term suddenly receives a different definition, the flow may have crossed a Bounded Context. Event clusters suggest candidate contexts, but responsibility and integration contracts still need validation.
After the session, move relationships to a Context Map and define which facts each context publishes, which commands it accepts, and where an Anti-Corruption Layer is needed.
From Event Storming to a DDDesigner model
Remove duplicate events, agree on terms, and connect every Command to the Aggregate that handles it. Commands and events around one set of immediate invariants form an Aggregate candidate. Stateless reactions become Policies, stateful long-running processes become Sagas, and information for screens and reports becomes Projections.
A Business Action connects user intent to its starting Command or route and expected outcomes. This turns a workshop artifact into a model that can be structurally checked against the required business result.
Common mistakes
Do not turn the session into a presentation of a finished architecture. Do not start from database tables, REST endpoints, or microservice names. Do not label every technical message a Domain Event or hide disagreement to make a clean linear diagram.
Another mistake is leaving the result as a photograph. Normalize the model, assign unresolved questions, and transfer confirmed decisions into a maintained architectural representation.
Event Storming outcome checklist
A session is useful when it produces a reviewable understanding of behavior, not merely a sequence of notes.
- Are Events meaningful business facts?
- Do Commands express intent rather than technical calls?
- Are alternative and failure paths visible?
- Is decision ownership clear?
- Do Hotspots have owners and next actions?
- Are candidate contexts, Aggregates, Policies, and Sagas identified?
- Has the result been transferred into a maintained model?
DDDesigner
Example: support ticket lifecycle
A customer issues the OpenTicket command and TicketOpened occurs. A Policy chooses a queue, an agent sends the AssignTicket command, and TicketAssigned updates the work list. As the SLA deadline approaches, an escalation Saga emits EscalationStarted and waits for an owner response. CustomerReplied returns the ticket to active work; ResolveTicket enforces the required resolution; TicketResolved updates the history projection. Reopening, unavailable agents, and manual escalation are modeled explicitly because those paths reveal the real Ticket Aggregate and SLA process rules.
Start free