Event Storming

Event Storming is run live, in a room (or a shared virtual whiteboard) with the people who actually understand the business process and the people who will build it, standing in front of a wall large enough that nobody has to scroll or paginate to see the whole thing at once. Richardson’s Microservices Patterns 5.3.4 and Vernon’s DDD Destilado ch. 7 both frame it the same way: the value is not the sticky notes themselves, it is the conversation the act of placing them forces — a domain expert who says "and then the order gets approved" prompts an immediate "approved by what, exactly, and what if it isn’t?" from whoever is holding the next sticky note, surfacing disagreements and gaps a written specification would have let slide past unnoticed.

Brandolini describes three levels a session can run at, each answering a different question and each useful at a different point in a project’s life:

A team new to the technique typically runs these levels in that order across a project’s lifetime — big-picture once, early; process-level per major flow as it is understood; design-level repeatedly, whenever a bounded context’s aggregate boundaries need re-examining — rather than jumping straight to design-level on a domain nobody has mapped yet.

The tooling is deliberately low-tech: a wall (or a shared virtual whiteboard) long enough that the whole flow being modeled fits without scrolling, a roll of paper or a whiteboard surface, and pads of the colored sticky notes the grammar below defines — nothing more elaborate is needed, and Brandolini is explicit that reaching for a heavyweight modeling tool too early gets in the way of the conversation the exercise exists to produce. Three roles matter more than any tool choice:

Every element on the board is a colored sticky note, and the color is the notation — there is no separate legend to consult once a team has run a session or two, because the same palette is reused every time:

Design-level modeling, the level this section’s running board is drawn at, proceeds in three passes over the same wall, each pass adding one more color and one more layer of structure on top of what the previous pass already placed — Richardson’s Microservices Patterns 5.3.4 states them in exactly this order:

By the end of the third pass, reading left to right along the timeline the events were arranged in reproduces almost exactly the shape of a use-case walkthrough: command arrives, an aggregate decides, an event results, possibly triggering the next command via a policy.

A design-level board’s structure maps onto this section’s other pages with almost no translation needed. Clusters of aggregates that exchange events and commands only among themselves, with comparatively few notes crossing to another cluster, are exactly the seams Strategic Design draws bounded-context boundaries along — the running domain’s board below clusters into the same four bounded contexts (Order, Inventory, Payment, Shipping) that page’s context map already names. Every yellow aggregate note becomes a page-3 aggregate root, sized and bounded by the rules Aggregates states. A chain of policy notes that fire across multiple aggregates in sequence — OrderPlaced triggers ReserveInventoryCommand, InventoryReserved triggers AuthorizePaymentCommand, and so on — is a saga read directly off the wall, choreography-style; deciding to replace that chain of policies with a single orchestrator is exactly the choreography-vs-orchestration choice Sagas covers, made after the board already shows which steps exist and in what order, not before.

The workshop format travels well to a distributed team: the same sticky-note grammar works unchanged on a shared virtual whiteboard (Miro, FigJam, or a purpose-built Event Storming tool), with the same three passes run over a video call instead of a physical room. What is harder to preserve remotely is the side-conversation density a shared physical wall naturally produces — a facilitator running a remote session typically needs to be more deliberate about explicitly inviting disagreement ("does everyone agree this event happens here?") since the informal, overheard "wait, that’s not right" that a shared room produces for free does not happen automatically over a call.

After the workshop, the board is not an artifact to file away — it is the input to the design work this section’s other pages already cover: hot spots get triaged into follow-up conversations or spikes before design starts on the aggregates they touch; the aggregate notes feed directly into Strategic Design's context-mapping exercise and Aggregates' boundary rules; and the event notes become the actual DomainEvent types Domain Events shows how to shape, name, and publish. A board that is photographed once and never revisited has already lost most of its value — the practical pattern is to re-run the design-level pass whenever a bounded context’s aggregate boundaries are being reconsidered, using the previous board as the starting point rather than a blank wall.

No code example belongs on this page — Event Storming is a facilitation technique, not a programming structure, and everything it produces is already expressed as code on the pages linked throughout this one. What belongs here instead is the running domain’s own board, reproduced as a figure, so a reader can see exactly where the Order, Inventory, Payment, and Shipping aggregates and their events came from before any of this section’s other pages had written a line of Java:

Reading the board left to right names exactly the aggregates, commands, and events every other page in this section already uses:

This is the same Place Order Saga Sagas walks through in full, including its compensation and failure branches — the board above shows only the happy path, since a design-level Event Storming board is typically drawn happy-path-first and then annotated with failure branches and hot spots in a second pass once the main flow is agreed on.