Event Storming

Event Storming is a fast, collaborative workshop for discovering how a business domain really works by mapping the events that happen in it. You put domain experts and engineers around a wall of sticky notes, walk the flow of events end to end, and surface the commands, actors, policies, and boundaries along the way. It is how we build a shared understanding before we model code.

Invented by Alberto Brandolini, Event Storming starts from a deceptively simple question: what happens in this domain? Participants write domain events — past-tense facts like Payment Captured or KYC Case Approved — on orange stickies and arrange them in time order on a long wall. From there you layer on the commands that cause events, the actors who issue them, the policies that react, the external systems involved, and finally the natural boundaries between subdomains.

It is a discovery technique, not a deliverable — the output is shared understanding, a ubiquitous language, and candidate boundaries, which then feed real design work. It maps directly onto the building blocks of Event-Driven Architecture, Event Sourcing (the events you storm are often the events you store), and Domain Modelling & Boundaries. Use it at the start of anything non-trivial, especially in a domain as nuanced as AML/KYC.

Run the workshop well

• DoGet the real domain experts in the room, not just engineers. The whole value is the knowledge that lives in their heads colliding with how the system actually behaves.
• DoWrite domain events as past-tense facts (`Document Verified`, `Sanctions Match Found`) and place them on a timeline. Resist jumping to solutions — first just map what happens.
• DoLayer the model incrementally: events first, then the commands and actors that cause them, then policies ("whenever X, then Y"), then external systems and read models.
• DoMark hotspots — disagreements, unknowns, painful areas — with a distinct colour. The arguments are signal: they show where the domain is genuinely unclear or risky.
• ConsiderDifferent levels for different goals: big-picture storming to explore a whole domain, process-level to detail one flow, design-level to derive aggregates and boundaries.
• AvoidTurning it into a database-schema or UI-wireframe session. Event Storming is about behaviour and language; modelling tables too early collapses the exploration.

Turn the wall into design

• DoCapture the ubiquitous language that emerges — the exact words experts use — and carry it verbatim into code, APIs, and docs (see Domain Modelling & Boundaries).
• DoUse the clusters of cohesive events and commands as candidate aggregates and bounded contexts — the seams where you'll later split services or modules.
• ConsiderFeeding the discovered events straight into an event-sourced or event-driven design where the history matters, since you've already named the facts (see Event Sourcing).
• DoRecord the hotspots as explicit follow-up questions or risks, so the unknowns surfaced in the room don't quietly vanish afterwards.

Self-review checklist

• AskWere the people who actually understand the domain in the room?
• AskAre my events real past-tense business facts, in the language experts use?
• AskDid the boundaries and aggregates emerge from the model, or did I impose them?
• AskDid I capture the hotspots and disagreements as follow-ups rather than papering over them?