From a room full of sticky notes to a domain model your team actually owns
What the technique is, how it works, and why it produces results that no other workshop format does
Alberto Brandolini invented Event Storming in 2013 as a direct response to a problem he kept encountering: the people who understood the business couldn't communicate it to the people building the software, and the usual workshop formats made this worse rather than better.
The standard requirements gathering meeting follows a predictable pattern. A business analyst prepares an agenda. Stakeholders sit around a table. Someone presents slides. People discuss. A BA takes notes. Three weeks later a requirements document appears that nobody fully agrees with, and development begins on a shared misunderstanding.
The people who know the domain — the operations manager who has processed ten thousand orders, the customer service lead who knows every edge case because she's handled them — sit quietly while the BA translates their world into a format that loses most of the nuance. The developers get a sanitised, incomplete picture. The domain experts never see whether their knowledge was captured correctly.
Brandolini's insight was simple: put everyone in the same room, give them sticky notes, and let the knowledge surface directly — without a translator in the middle.
Event Storming: A collaborative workshop technique invented by Alberto Brandolini for rapidly exploring complex business domains. It brings together domain experts and technical teams to build a shared understanding of what happens in a business — expressed as a timeline of Domain Events on a large wall. The output is a visual model of the domain that both sides created and therefore both sides understand.
Three things separate Event Storming from conventional requirements workshops.
First, it starts with what happens rather than what exists. Most requirements processes start with entities — what are the things in the system, what are their attributes? Event Storming starts with events — what happens in the business, in what order, under what conditions? This shift from nouns to verbs surfaces the dynamics of the domain in a way that entity-first approaches miss.
Second, it is radically inclusive. Everyone who touches the domain is in the room — domain experts, developers, architects, product owners, sometimes customers. No single person has the full picture. The operations manager knows the fulfilment process in detail but has never thought about how the pricing engine works. The developer knows the pricing code but doesn't understand the business rules behind it. The model that emerges from the combined room is more complete than anything any individual could produce.
Third, it is deliberately low-tech. Sticky notes on a paper roll. No slide decks, no whiteboards filled with UML, no elaborate tooling. The low-tech constraint is a feature — it makes participation equal. Everyone can write on a sticky note. Nobody needs a specialised skill to contribute.
A Big Picture Event Storming session — the strategic variant — produces a timeline of Domain Events covering an entire business process from end to end. Hotspots mark the places where things go wrong or where the team has disagreements. Pivotal events mark the major business transitions. Boundaries between business areas emerge naturally from where the language and the people change.
A more detailed session adds Commands (what triggers each event), Actors (who issues each command), Policies (what happens automatically in response to events), and eventually Read Models and Aggregates. At Design Level, the output is close enough to a software specification to drive development directly.
Event Storming is not a design methodology. It doesn't tell you how to build the system — it tells you what the system needs to do and where the genuine complexity lives. It is a discovery tool, not a design tool.
It is not a one-time exercise. A domain understanding that took one session to surface will need revisiting as the team learns more, as the business changes, and as assumptions get challenged by implementation reality.
And it is not a substitute for DDD. Event Storming is the fastest way to surface the raw material — the events, the language, the boundaries — that DDD concepts then help you structure into a coherent model. The two are complementary, not competing.
Next: the sticky note vocabulary — what each colour means and why the colour coding matters.
Event Storming has a visual vocabulary. Each type of concept gets its own sticky note colour, and the colour coding is not decoration — it is the grammar of the shared language the session builds. Get the colours right and the wall becomes readable. Ignore them and the wall becomes noise.
Different facilitators use slightly different colour conventions, but Brandolini's original mapping has become the standard. Here it is, with the reasoning behind each choice.
The most important sticky note in the session. A Domain Event is something that happened in the business that the business cares about. Written in past tense, in the language of the domain: OrderPlaced, PaymentReceived, StockReserved, CustomerRegistered, ShipmentDelayed.
Orange dominates the wall for good reason — events are the skeleton of the session. Everything else attaches to them. The first instruction every participant receives is: write what happens on orange stickies, in past tense, and put them on the wall.
Past tense. Business language, not technical language. Meaningful to the business, not just to the system. OrderConfirmed — good. OrderStatusUpdated — bad (that's a database operation, not a business fact). CustomerCreditChecked — good. CreditCheckAPICallMade — bad. If the event name would make sense in a conversation with the operations team, it's a Domain Event. If it would only make sense to a developer, rewrite it.
A Command is what triggers a Domain Event. It is an instruction — something a person or system does that causes something to happen. Written in imperative form: Place Order, Confirm Payment, Reserve Stock, Register Customer.
Commands are added in Process Level sessions, not in the initial Big Picture pass. At the Big Picture level, the team focuses on events first. Commands come later, when the team starts asking "but what causes this event to happen?"
A Policy is an automatic reaction — something the system does when an event occurs, without human intervention. Written as a rule: "Whenever OrderPlaced, reserve stock automatically." or "Whenever PaymentDeclined, notify customer and release reservation."
Policies are where business logic lives. They are the conditional rules that govern how the business responds to things that happen. Finding them is one of the most valuable outputs of a detailed Event Storming session — because they are often implicit, assumed by the domain experts to be obvious, and never written down anywhere.
In Design Level sessions, yellow stickies represent two different things depending on their orientation. Aggregates — the clusters of domain objects that enforce business rules — are written on yellow stickies placed between the Command and the Event it produces. Read Models — the views of data that an Actor needs to make a decision — are also yellow, placed before the Command that needs them.
An Actor is the person or role that issues a Command. Small pink stickies attached to blue Command stickies: Customer, Warehouse Operative, Finance Manager, System Administrator. Actors help the team see who is responsible for what and where automation could or should replace human action.
The most direct sticky note in the session. A Hotspot marks a problem, a disagreement, an area of uncertainty, or a question nobody can answer in the room. Written on red stickies and placed prominently on the wall. The instruction to participants: if something is unclear, broken, contested, or unknown — put a red sticky on it and move on. Don't stop the session to resolve it.
By the end of the session, the density of red stickies is a heat map of risk. Clusters of red reveal the genuinely complex and contested areas. These become the priority agenda for follow-up conversations.
Green stickies capture insights and opportunities that emerge during the session — process improvements, automation possibilities, things the business could do differently. They're not part of the domain model; they're the byproduct of having knowledgeable people in the same room looking at the whole picture together.
External systems — payment gateways, logistics APIs, ERP systems, third-party services — that interact with the domain but sit outside it. Lilac stickies placed where the external system triggers or receives events make the integration points visible without conflating external systems with internal domain logic.
Next: the three variants of Event Storming and when to use each one.
Event Storming isn't one fixed workshop format — it's a family of three related techniques at different levels of detail. Knowing which one to run, and when, is the first decision any facilitator has to make.
The strategic variant. Covers an entire business domain — or a large slice of it — at high altitude. The goal is shared understanding across the whole landscape: what happens, in what order, where the problems are, and where the natural boundaries between business areas sit.
A Big Picture session typically runs a full day, sometimes two. It brings in the widest possible range of participants — domain experts from multiple departments, leadership, developers, architects. Nobody needs technical knowledge to participate. The only requirement is that participants know something about how the business works.
The outputs of a Big Picture session are: a timeline of Domain Events from end to end, Hotspots marking problem areas and disagreements, Pivotal Events marking major business transitions, and emerging context boundaries where the language and participants naturally shift.
At the start of a significant project or programme, before any design decisions are made. When joining an existing domain you don't understand. When a team has lost alignment on what the system actually does. When a business is exploring a new product or capability. Big Picture is the discovery tool — run it whenever you need to see the whole landscape before deciding where to dig.
The operational variant. Zooms into a specific business process identified during the Big Picture session — typically one that's complex, contested, or targeted for change. Adds Commands, Actors, and Policies to the event timeline, making explicit who does what, what triggers each event, and what happens automatically.
A Process Level session typically runs half a day to a full day, with a smaller group — the people who actually own and work within the specific process being explored. The outputs are a detailed process model showing the full sequence of commands, events, actors, and policies — complete with all the edge cases and exception paths that never make it into formal documentation.
After a Big Picture session, to explore specific processes in detail. Before redesigning a complex workflow. When a team needs to understand a process deeply enough to automate it or build software to support it. Process Level is the analysis tool — run it when you need to understand a specific slice of the domain well enough to act on it.
The technical variant. Takes the output of a Process Level session and translates it into a software model — Aggregates, Commands, Events, Policies, Read Models, and the relationships between them. This is where the DDD tactical patterns enter the picture, directly informed by the domain understanding built in the earlier sessions.
A Design Level session runs two to four hours, with a small group — typically the development team plus one or two domain experts to answer questions. The outputs are close to a software specification: Aggregates with their Commands and Events, Read Models with their data requirements, integration points between Bounded Contexts, and a clear picture of what the software needs to do at the level of individual domain operations.
Immediately before beginning development on a specific feature or bounded context. When translating a well-understood process into a software model. When the development team needs shared understanding of what they're about to build. Design Level is the specification tool — run it when you need to turn domain understanding into actionable technical direction.
No. The variants are not a mandatory sequence. For a well-understood domain where the team already has strong domain knowledge, a Design Level session might be all that's needed before starting work on a new feature. For a brand new product or a legacy system nobody fully understands, all three — in sequence — give the clearest path from confusion to clarity.
The rule of thumb: start at the level of detail that matches the level of uncertainty. High uncertainty about the whole domain — start Big Picture. Understood domain, unclear process — start Process Level. Understood process, ready to build — start Design Level.
Next: preparing the room and the people — what you need before the session starts.
Step by step through the four phases of a Big Picture Event Storming workshop at Meridian Retail
A poorly prepared Event Storming session wastes everyone's time. The preparation isn't complicated — but skipping it produces predictable failures: wrong people in the room, not enough wall space, sticky notes that fall off, participants who don't know why they're there.
The single most important physical requirement is wall space. An Event Storming session for a business domain of any real complexity needs at minimum six metres of continuous wall. Eight to ten metres is better. The wall is the shared workspace — events go left to right in time, and the further right you go, the more space you need for the events and everything that attaches to them.
The standard solution is a roll of plain paper — the kind used for packaging — taped horizontally across the wall. This creates a writable, sticky-note-friendly surface of whatever length you need. It also means the output is portable: you can roll it up, photograph it, and bring it back to the next session.
The room needs to be large enough for the whole group to stand at the wall simultaneously. No chairs. Event Storming is a standing workshop by design — it keeps energy up, keeps people moving to different parts of the wall, and prevents the passive lecture-room dynamic where a few people speak and everyone else listens.
Prepare these before anyone arrives:
Orange sticky notes — large quantity, at least 200 for a full day session. Blue, purple, pink, red, green, lilac, and yellow stickies in smaller quantities. Thick felt-tip markers — not ballpoints. The writing must be readable from two metres away. Paper roll taped to the wall. A legend visible to everyone showing each colour and what it means.
The thick marker requirement is non-negotiable. Ballpoint pens produce writing nobody can read from a distance, which means nobody reads it, which means the wall stops being a shared reference and becomes one person's private notes. If people can't read the wall from across the room, the session has already failed.
For a Big Picture session, the invitation list should span the entire domain. At Meridian Retail, a session covering the end-to-end order journey would include: someone from the customer-facing team who understands how orders are placed, the operations manager who runs the fulfilment process, a finance representative who understands billing and reconciliation, the warehouse manager, the customer service lead who handles problems and returns, and developers and architects who will build or maintain the systems involved.
The ideal group size is between eight and thirty people. Fewer than eight and you risk missing critical domain knowledge. More than thirty and facilitation becomes unmanageable.
Every person in the room should either know something about the domain that others don't, or need to understand something about the domain that they currently don't. If someone fails both tests, they probably shouldn't be there. Event Storming works because of the diversity of knowledge in the room — filling it with observers or bystanders dilutes that.
Send participants a one-paragraph briefing before the session. Tell them what Event Storming is, what they'll be doing (writing on sticky notes, standing at a wall, discussing what happens in the business), and what the session will produce. Tell them explicitly that no preparation is required — they only need to show up knowing what they know.
At the start of the session, spend ten minutes on a brief introduction: what a Domain Event is, what orange stickies are for, and the first instruction. Don't over-explain the technique — participants learn by doing, not by listening to a methodology briefing. Get stickies on the wall within the first fifteen minutes.
A full Big Picture session for a domain of moderate complexity runs six to eight hours. Allow for breaks — Event Storming is mentally intensive and the quality of discussion drops sharply when people are tired. A structure that works well: ninety minutes of chaotic exploration, thirty-minute break, ninety minutes of timeline enforcement and hotspot marking, lunch, ninety minutes of pivotal events and boundary finding, thirty minutes of debrief and next steps.
Next: Phase 1 — Chaotic Exploration, the most energetic and productive part of the session.
The first phase of a Big Picture session is intentionally unstructured. No order, no agenda, no turn-taking. Just everyone writing Domain Events on orange stickies and putting them on the wall simultaneously. The chaos is the point.
The facilitator's opening instruction is simple: "Write everything that happens in this business on orange sticky notes, in past tense, and put them on the wall. Write one event per sticky. Don't worry about order. Don't discuss. Just write and stick."
Then step back and let it happen.
For the first few minutes, the room will feel awkward. People will look at each other, unsure whether to start. The facilitator's job is to resist the urge to fill the silence with more explanation. Write the first sticky yourself — OrderPlaced — and put it on the wall. Someone will follow. Then another. Within five minutes the room is alive.
At Meridian Retail, the first fifteen minutes of a Big Picture session on the order journey produces a wall covered in orange stickies: CustomerRegistered, OrderPlaced, PaymentReceived, StockChecked, PickListGenerated, OrderPicked, OrderPacked, OrderDispatched, OrderDelivered, ReturnRequested, RefundIssued, ReviewSubmitted, LoyaltyPointsAwarded, PromotionApplied, StockReplenished, SupplierInvoiceReceived.
Not in any particular order. Not in any particular location on the wall. The operations manager puts up events about the warehouse process. The finance person puts up events about billing and reconciliation. The customer service lead puts up events about complaints and returns. The developer puts up events about system integrations. All simultaneously, all from their own perspective.
This is the point. Nobody has the full picture. The wall is the first time everyone can see the whole picture at once.
Within minutes, duplicates will appear. Three different people have written variations of OrderConfirmed: one says OrderConfirmed, one says OrderApproved, one says OrderAccepted. Leave them all up. These apparent duplicates are often not duplicates at all — they represent subtly different events in different parts of the process, or different people's understanding of the same event. The conversation about whether these are the same thing or different things is valuable. Don't collapse it prematurely.
Contradictions will also appear. One person writes StockChecked before PaymentReceived. Another writes it after. Both might be correct — the business might check stock at two different points. Or the two people have different mental models of the same process. Either way, that contradiction is information. Mark it with a red Hotspot sticky and continue.
Keep the energy up. Encourage quiet participants to write. Gently stop people who are getting into lengthy discussions — the instruction is to write, not to debate. If someone raises a question that needs discussion, write it on a red Hotspot sticky and keep moving. The goal of this phase is volume — get everything out of people's heads and onto the wall. Refinement comes later.
Phase 1 is complete when the rate of new stickies going on the wall slows significantly — when most people are standing back, reading the wall rather than writing. This typically takes forty-five minutes to ninety minutes. Don't cut it short — the last stickies to go up are often the most interesting, the edge cases and exceptions that people only think of after they've already externalised everything obvious.
Next: Phase 2 — bringing order to the chaos by enforcing the timeline.
After the chaotic explosion of Phase 1, the wall is covered in orange stickies with no discernible order. Phase 2 imposes structure: events get arranged left to right in the order they happen in the real world. This is where the first major insights emerge.
The facilitator introduces a simple rule: events that happen earlier go to the left, events that happen later go to the right. The group begins moving stickies into rough chronological order — not precise to the minute, but correct in sequence.
At Meridian Retail, the group quickly agrees that CustomerRegistered comes before OrderPlaced, which comes before PaymentReceived, which comes before StockReserved. This part is straightforward. But then the debate starts: does StockChecked come before or after PaymentReceived? The operations team says stock is checked at the point of order placement. The finance team says payment is taken before stock is reserved. Both turn out to be true — there's a preliminary stock check at order placement and a firm reservation after payment. These are two different events that had been collapsed into one sticky.
This is the kind of insight that never surfaces in a requirements workshop. It surfaces here because the timeline makes the question unavoidable.
Real business processes don't happen in a single linear sequence. Multiple things happen simultaneously — while the warehouse is picking the order, the finance team is reconciling the payment, and the marketing system is triggering a post-purchase email. The wall accommodates this by allowing multiple horizontal tracks: events that happen in parallel with each other are placed above and below each other at the same horizontal position.
At Meridian Retail, the point of order dispatch triggers three simultaneous tracks: the logistics track (ShipmentBooked, CourierCollected, OrderInTransit), the customer communication track (DispatchEmailSent, TrackingLinkProvided), and the financial track (InvoiceGenerated, RevenueRecognised). These run in parallel until OrderDelivered brings them back together.
Phase 2 surfaces the most productive disagreements of the session. When two people put the same event in different positions on the timeline, resist the urge to resolve it immediately by voting or by deferring to the most senior person in the room. Instead, ask: "Are these the same event, or are they different events that have been given the same name?" Often the answer reveals that two genuinely different things have been collapsed into one concept — and separating them produces a clearer model.
When the disagreement is genuine — the same event, contested position — put a Hotspot sticky on it and move on. The goal of Phase 2 is a rough timeline that everyone broadly agrees with, not a perfect sequence that everyone has signed off on. Perfection comes later, if it comes at all.
Next: Phase 3 — finding the hotspots, problems, and pivotal events that shape the model.
With the timeline roughly in order, the session shifts from building the model to interrogating it. Phase 3 is where the most valuable outputs of a Big Picture session emerge — the places where things go wrong, the major business transitions, and the edges of the domain.
The facilitator guides the group on a structured walk from left to right along the timeline. At each event, the question is simple: "Does anything go wrong here? Is there anything we don't understand? Does anyone disagree with this?"
At Meridian Retail, the walk surfaces immediately useful information. At PaymentReceived, the finance manager raises her hand: "What happens when payment is received but the stock check subsequently fails? We've had cases where we've taken payment and can't fulfil." Red sticky. At ReturnRequested, the customer service lead says: "This is a disaster. We have four different return processes depending on the product category and nobody knows which one applies." Red sticky. At LoyaltyPointsAwarded, a developer says: "I'm not sure this ever actually happens in real time — I think it's a batch job that runs overnight." Red sticky, and a very interesting conversation about whether the event model matches the implementation.
The density and location of red Hotspot stickies by the end of Phase 3 is one of the most useful outputs of the entire session. It is a risk map — a visual representation of where the process is fragile, contested, or poorly understood. Areas with many Hotspots are the places that need the most design attention. Areas with no Hotspots are either genuinely well-understood or haven't been examined carefully enough.
A cluster of red stickies around a single event almost always indicates a boundary problem — this event means different things to different teams, or it sits at the edge of two different business processes that haven't been properly integrated. A long section of the timeline with no red stickies should prompt the facilitator to ask: "Is this section genuinely well-understood, or did we just not look hard enough?" Both answers are important.
Some Domain Events are more significant than others. They represent major transitions in the business process — points where the nature of what's happening fundamentally changes, where responsibility shifts from one team to another, or where a business commitment is made that's difficult to reverse.
At Meridian Retail, the pivotal events are clear once you look for them: OrderConfirmed (the customer has committed, the business has committed), PaymentReceived (financial obligation transferred), OrderDispatched (fulfilment is now in the hands of logistics), OrderDelivered (the transaction is complete). These pivotal events often align with natural context boundaries — the team and language that owns the process frequently shifts at these points.
Mark pivotal events with a vertical line on the wall, or with a distinct label. They become the skeleton around which the context map is built in Phase 4.
By the end of Phase 3, something interesting has happened to the room. People who didn't know each other's work well have spent hours looking at the same picture together. The operations manager understands for the first time how the customer service process works. The developer understands why the overnight batch job causes the customer service team problems the next morning. The finance manager understands why the returns process produces reconciliation headaches.
This shared understanding is not a byproduct of Event Storming — it is one of its primary outputs. A team that has built a model together owns that model in a way that no team handed a requirements document ever does.
Next: Phase 4 — finding the natural boundaries in the domain.
The final phase of a Big Picture session turns observation into structure. With the timeline built and the hotspots marked, the group can now see the natural boundaries in the domain — where one area of the business ends and another begins.
One of Brandolini's key insights is that Bounded Context boundaries shouldn't be designed top-down by an architect with a whiteboard. They should emerge from the domain itself — from where the language changes, from where the team and responsibility shifts, from where the pivotal events mark major transitions.
By Phase 4 of a Big Picture session, these signals are visible on the wall. The facilitator's job is to help the group see what's already there.
Walk the timeline and watch for where the vocabulary shifts. At Meridian Retail, the events up to OrderConfirmed use customer-facing language: CartCreated, ProductAdded, DiscountApplied, CheckoutStarted. After OrderConfirmed, the language shifts to operational language: PickListGenerated, BinLocation, PickConfirmed, PackingSlipPrinted. Different words. Different world. That shift marks a natural boundary.
Similarly, around PaymentReceived, financial language enters: InvoiceGenerated, RevenueRecognised, TaxCalculated, ReconciliationEntry. Different again. Another boundary.
Watch who is engaged at each part of the wall. The warehouse manager is animated during the fulfilment section and disengaged during the online checkout section — because the online checkout is not her domain. The finance team clusters around the billing and reconciliation events. These natural groupings often correspond directly to the Bounded Contexts — each context is the domain of a particular team.
Once the language and people signals have been observed, the facilitator draws provisional boundary lines on the wall — vertical lines separating the sections. These aren't final design decisions. They're hypotheses. The group discusses each one: does this feel like a real boundary? Is there anything that crosses it that shouldn't? Is there anything currently on one side that belongs on the other?
The boundaries identified in Phase 4 are inputs to the DDD strategic design work — they become candidate Bounded Contexts on the Context Map. They're not final. Naming them, validating them with the teams involved, and testing them against the integration patterns described in the DDD guide turns them from observations into design decisions.
Before the session ends, photograph everything. The entire wall, then close-ups of each section. The hotspot clusters. The boundary lines. The pivotal events. This documentation is the output that enables the next steps — whether that's a Process Level session on a specific area, a Context Map design exercise, or the beginning of a development programme.
Next: Process Level Event Storming — adding Commands, Actors, and Policies to one specific process.
Going deeper — from the whole domain to individual processes to the software model
A Process Level session takes one slice of the domain identified in the Big Picture session and examines it in detail. The goal is a complete model of a specific process — every trigger, every automatic reaction, every human decision point — expressed in a form that a development team can act on.
At Meridian Retail, the Big Picture session identified the returns and refunds process as a major Hotspot — four different return processes, significant customer service pain, unclear ownership. This makes it an obvious candidate for a Process Level session. Other candidates are processes where the Big Picture output showed the most red stickies, processes that are targeted for automation, or processes where the team has significant disagreements.
The session starts with the Domain Events from the Big Picture, arranged in timeline order. The first addition is Commands — the instructions that trigger each event.
For each Domain Event on the wall, the group asks: "What caused this to happen? What instruction was issued, and by whom?" The answer goes on a blue sticky placed to the left of the event it triggers: RequestReturn → ReturnRequested. ApproveReturn → ReturnApproved. IssueRefund → RefundIssued.
Commands that can be rejected — where the business might decide not to fulfil the instruction — are particularly valuable to identify. If RequestReturn can result in either ReturnApproved or ReturnRejected, both outcomes need to be on the wall, with the decision criteria made explicit.
For each Command, the group asks: "Who issues this instruction?" Pink stickies attached to the Command: Customer issues RequestReturn. Customer Service Agent issues ApproveReturn or RejectReturn. Finance System issues IssueRefund automatically once approval is received.
The Actor assignment immediately surfaces automation opportunities and ownership questions. When the Actor for a Command is a human doing something manually that could be automated, that's a green Opportunity sticky. When the Actor is unclear — nobody is sure who is responsible for issuing a particular Command — that's a red Hotspot sticky.
Policies are the automatic reactions — the "whenever X happens, Y happens automatically" rules that encode business logic. In the returns process at Meridian Retail, policies include: "Whenever ReturnApproved and ReturnedItemReceived, issue refund automatically." "Whenever ReturnRequested and order is more than 30 days old, flag for manual review." "Whenever RefundIssued, notify customer by email."
Policies are the hidden logic of the business. They're almost never written down anywhere. Domain experts often assume they're obvious — and they are, to someone who has worked in the business for years. To a developer building the system, they're invisible until someone trips over their absence. The Process Level session makes them visible.
Next: Design Level — translating the process model into Aggregates and a software design.
Design Level is the final step in the Event Storming journey — the point where the domain understanding built in Big Picture and Process Level sessions becomes a concrete software model. This is where the DDD tactical patterns enter the picture directly.
A Design Level session begins with the output of a Process Level session: a timeline of Commands, Events, Policies, and Actors for a specific process. The group is now smaller — primarily developers and architects, with one or two domain experts available to answer questions.
The question the session answers is: "Given this process model, what Aggregates do we need, and how do they relate to each other?"
For each Command-Event pair on the wall, the group asks: "What domain object receives this Command and produces this Event?" The answer — the Aggregate — goes on a yellow sticky placed between the Command and the Event.
At Meridian Retail, RequestReturn → [ReturnRequest] → ReturnRequested. ApproveReturn → [ReturnRequest] → ReturnApproved. The ReturnRequest Aggregate handles both Commands and maintains the state of the return. The group then discusses what data the ReturnRequest Aggregate needs to hold and what invariants it must enforce — can it approve a return that's already been rejected? Can it accept a new command after approval? These are the business rules the Aggregate will encode.
For each Command, the group asks: "What information does the Actor need to make this decision?" That information — a view of the current state — goes on a yellow sticky to the left of the Command. At Meridian Retail, before a customer service agent can issue the ApproveReturn Command, they need to see the order history, the return reason, and the current stock levels for the returned item. That's a Read Model: ReturnDecisionView. It becomes a defined data requirement — the system must be able to surface this information to the Actor at the right moment.
Lilac stickies mark where the process touches external systems. At Meridian Retail, the refund process triggers the payment gateway (RefundIssued calls the payment provider's API) and the email system (CustomerNotified calls the notification service). These integration points, made explicit in the Design Level output, become the integration contracts that the development team builds against.
By the end of a Design Level session, the team has: a named set of Aggregates with their Commands and Events; Read Models with their data requirements; integration points with external systems; and a clear picture of the Policies that govern automatic reactions. This output is close enough to a software specification that a skilled development team can begin building immediately, with confidence that what they build will reflect the domain correctly.
Design Level Event Storming and DDD tactical design are the same exercise approached from different directions. Event Storming approaches from the outside — what happens in the business — and works inward to the software model. DDD tactical design approaches from the inside — what patterns does the code need — and works outward to the domain. When both are done well, they meet in the middle at the same model.
Teams that run Design Level sessions find that the DDD concepts from the companion guide map directly onto the sticky notes on the wall. Aggregates are the yellow stickies. Commands are the blue stickies. Domain Events are the orange stickies. Policies are the purple stickies. The visual vocabulary of Event Storming and the conceptual vocabulary of DDD are two languages for the same thing.
Next: the facilitation skills that keep a session on track — and the interventions that save it when it isn't.
Facilitation, remote workshops, and the failure modes that derail Event Storming sessions
Event Storming facilitation is a distinct skill. The techniques that work in a conventional meeting — structured agenda, turn-taking, slides — actively harm an Event Storming session. The facilitator's job is to create conditions for the group to work, then get out of the way.
The most common facilitation mistake is the facilitator trying to guide the domain model. "Shouldn't this event come before that one?" "I think these two events might be the same thing." The facilitator is there to manage the process, not to shape the content. The domain experts in the room know more about the domain than the facilitator. Every time the facilitator steers the content, they risk overriding knowledge they don't have.
The facilitator's legitimate interventions are procedural: "Let's get more stickies on the wall before we start discussing." "That sounds like a great conversation for a Hotspot sticky — let's keep moving." "Can someone who hasn't spoken yet tell us what they think about this section?" These interventions keep the process moving without shaping the model.
Every group has at least one person who talks more than everyone else combined. In a conventional meeting, this person controls the output. In Event Storming, the facilitator's job is to prevent this. Techniques that work: explicitly invite quiet participants by name. Physically position yourself near the dominant speaker and gently redirect with "let's hear from someone on the other side of the room." For persistent cases, split the group into smaller clusters for specific sections of the wall.
Event Storming's informality makes some participants — typically senior technical people and process-minded managers — visibly uncomfortable. "This feels unstructured." "Where's the template?" "How do we know we've covered everything?" The best response is not to defend the technique but to redirect to the output: "Let's keep going and see what the wall looks like in an hour." The sceptic who has been resistant for the first thirty minutes is often the most engaged participant by lunchtime.
Event Storming sessions follow a predictable energy pattern. The first thirty minutes are awkward — people aren't sure what to do. The next hour is energetic — everyone is contributing, the wall is filling up, insights are emerging. Then energy drops as people get tired and the easy stickies are exhausted. This is the moment to call a break, not to push through. After the break, the second burst is often more focused and produces the most valuable insights.
Keep each phase to its allocated time. The chaotic exploration phase has a tendency to expand as participants find more things to add. Cut it at ninety minutes maximum, even if new stickies are still going up. The timeline enforcement phase has a tendency to get bogged down in debates about specific sequences — use Hotspot stickies to park debates and keep moving. The facilitator is the timekeeper, and time discipline is one of the most important contributions they make.
When the group starts to debate rather than model — when people are having a long discussion instead of putting stickies on the wall — the facilitator's response is always the same: write it on a sticky and keep moving. Debates belong on Hotspot stickies. The session is for externalising knowledge, not for resolving it. Resolution happens in the follow-up work, informed by what the session surfaces.
Next: running Event Storming sessions when the room can't be in the same physical space.
Event Storming was designed for a physical room with a physical wall. Remote and hybrid variants work — but they require deliberate adaptation. The informal energy of a physical session is harder to create online, and the facilitation demands are higher.
The most common tools for remote Event Storming are Miro, Mural, and FigJam — collaborative infinite-canvas tools that support sticky notes, colour coding, and real-time multi-user editing. All three work adequately. None of them replicate the spatial freedom of a physical wall.
The choice of tool matters less than the setup. Before the session, the facilitator should prepare: a canvas with the colour legend visible at all times, a long horizontal strip for the timeline, and named zones for each participant so people don't pile their stickies on top of each other in the first chaotic phase.
Physical sessions benefit from ambient awareness — you can see what everyone else is doing, you naturally gravitate toward areas of the wall where there's interesting activity, you can have a side conversation with someone standing next to you without disrupting the group. None of these happen remotely.
Remote facilitation therefore requires more explicit structure. The facilitator narrates what's happening more actively. Breakout rooms replace the natural small-group conversations that form around sections of a physical wall. Check-ins are more frequent — "Has everyone had a chance to look at the logistics section? Does anyone want to add anything there?"
Hybrid Event Storming — some participants in a room, some remote — is significantly harder than either fully physical or fully remote. The in-room participants have an inherent advantage in the spontaneous interactions that drive Event Storming. The remote participants are always slightly behind the conversation.
If hybrid is unavoidable, the mitigation is to run the session primarily through the digital tool — even for the in-room participants — rather than having in-room participants use the physical wall while remote participants use the digital canvas. Equal access to the shared workspace is more important than the physical experience.
Keep remote sessions shorter than physical ones — four to five hours maximum per day, with more frequent breaks. Send participants a short video or written guide on the tooling before the session so that learning the tool doesn't consume the first thirty minutes. Use video throughout — Event Storming depends on seeing people's reactions, not just their sticky notes. And build in explicit time at the start for people to orient themselves on the canvas before the session begins.
Next: the failure modes that derail Event Storming efforts — and how to spot them early.
Event Storming fails in predictable ways. Most failures are not about the technique — they're about preparation, invitation, and facilitation decisions made before the session starts.
The most common failure. A session attended entirely by developers, or entirely by business analysts, or with one domain expert and fifteen observers, produces a model of what the attendees know — not a model of the domain. Event Storming's value comes from the collision of different knowledge perspectives. Without that diversity, it's an expensive way to do something a whiteboard session could have done.
The test: before the session, ask whether every significant area of the domain is represented by someone who actually works in it. If the answer is no, fix the invitation list before fixing the facilitation plan.
Facilitators who are uncomfortable with the apparent chaos of Phase 1 sometimes introduce structure prematurely — asking participants to take turns, organising stickies as they go up, or restricting the session to one part of the domain at a time. This kills the spontaneous cross-domain insights that are the most valuable output of the chaotic phase.
The chaos is not a problem to manage. It's the mechanism. The model that emerges from thirty people independently externalising their knowledge simultaneously is richer than any model that could have been constructed sequentially.
A Big Picture session that isn't followed by concrete next steps within two weeks produces energy but not change. The wall gets photographed. The photos get filed. Nothing happens. Six months later someone proposes another workshop to "align on the domain."
The session must end with defined follow-up actions: which areas will be explored in Process Level sessions, who owns each Hotspot, when the Context Map design exercise will happen. The output of Event Storming is not insight — it's the foundation for decisions. If decisions don't follow, the investment was wasted.
Domain understanding is not a deliverable. The model built in an Event Storming session reflects the group's understanding at that moment. As the team builds the software, as the business evolves, as edge cases surface that nobody anticipated, the model needs to be updated. Organisations that run a Big Picture session once and treat it as done have a model that becomes less accurate every week thereafter.
A facilitator who runs Event Storming but steers participants toward a model they've already designed in their head. The stickies go up, the wall fills, the session looks like Event Storming — but the output is what the facilitator already thought before the session started. Participants sense this and disengage. The knowledge in the room never makes it onto the wall.
The diagnostic: if the facilitator knows what the wall will look like before the session begins, something has gone wrong. A genuine Event Storming session always produces surprises.
Next: how the Event Storming outputs connect to the DDD concepts from the companion guide.
How Event Storming outputs become DDD models — and where all of this fits in a real project
Event Storming and DDD are designed to work together. The outputs of each Event Storming variant map directly to the DDD concepts covered in the companion guide. This chapter makes those connections explicit.
The Big Picture session produces the raw material for DDD's strategic patterns.
The language shifts on the timeline — where vocabulary changes from one area to the next — become the boundaries between Bounded Contexts. Each zone of consistent language is a candidate context with its own Ubiquitous Language.
The pivotal events that mark major business transitions are the natural integration points on the Context Map. The relationship pattern at each integration point — Conformist, Customer-Supplier, Anticorruption Layer, Shared Kernel — can be discussed and decided using the Context Map framework.
The people clusters — which domain experts engaged most strongly with which sections of the wall — map to team boundaries. Conway's Law suggests these team boundaries will eventually influence the system architecture, making the alignment between team and context even more important to get right.
The subdomain classification emerges from the combination of Hotspot density and business importance. Sections of the wall with many Hotspots and high business significance are candidates for Core Domain investment. Sections with few Hotspots and commodity characteristics point toward Generic Subdomain treatment.
The Process Level session produces a precise vocabulary for a specific Bounded Context. Every Command, Event, Policy, and Actor named in the session is a candidate term in the Ubiquitous Language of that context. The naming discipline of Event Storming — past tense events, imperative commands, named actors — enforces the same precision that DDD's Ubiquitous Language requires.
The Policies identified in a Process Level session are particularly valuable for Ubiquitous Language development. They make business rules explicit that were previously implicit — and naming them precisely is the first step to expressing them correctly in code.
The Design Level session produces a direct mapping to DDD's tactical patterns.
Run in sequence — Big Picture to establish context boundaries and language, Process Level to build precise process models within each context, Design Level to translate those models into software specifications — Event Storming and DDD together provide a complete path from business domain to working software. Neither is sufficient alone. DDD without Event Storming risks building a model that reflects the architect's assumptions rather than the business's reality. Event Storming without DDD produces a wall full of insights with no framework for turning them into a coherent model.
Together, they answer the question that every software project needs to answer before it begins: what is this software actually for, and does our model of the domain match how the business actually works?
Next: where Event Storming fits in a project lifecycle — and when to run each variant.
Event Storming isn't a phase in a project plan. It's a technique you reach for at specific moments — when domain uncertainty is high, when a team needs to align, or when a process needs to be understood before it can be changed. Knowing when to run it is as important as knowing how.
The clearest case. A new product or programme has a domain that nobody on the technical team fully understands yet. The business has knowledge that's never been externalised. A Big Picture session in the first two weeks — before any architecture decisions, before any backlog creation, before any sprint planning — surfaces that knowledge and prevents the most expensive class of mistake: building the right features on the wrong model.
At Meridian Retail, the decision to build a new returns management system should start with a Big Picture session on the returns and refunds process, attended by the customer service team, the warehouse team, the finance team, and the development team. Not after the system has been designed — before. The session might take a day. The alternative — building on assumptions and discovering the gaps after six months of development — takes considerably longer.
A development team inheriting a legacy system faces a specific knowledge problem: the system encodes business logic accumulated over years, the people who built it may have left, and the documentation is either absent or wrong. A Big Picture session on what the system is supposed to do — run with the people who actually use it, not the people who built it — produces a model of the intended behaviour that can then be compared to the actual behaviour. The gaps between the two are the technical debt that matters.
When a significant business process is being redesigned — for efficiency, for automation, for regulatory compliance — a Process Level session on the current state ("what actually happens now") before designing the future state prevents a common failure: designing a future that solves the imagined problem rather than the real one. The Hotspot stickies from a current-state session tell you exactly where the pain is. Design the future state to address those Hotspots specifically.
The most mature use of Event Storming is as a regular practice rather than a one-time project activity. Teams that run short, focused Process Level or Design Level sessions as part of their ongoing development process — before each significant feature, at the start of each quarter — maintain a living model of their domain that evolves with the business. The model never has a chance to drift.
Event Storming is compatible with Agile development — but it sits upstream of the sprint, not inside it. The outputs of a Big Picture session inform the product roadmap. Process Level sessions inform the feature backlog. Design Level sessions happen in the sprint zero or at the start of work on each new feature area.
Teams that try to run Event Storming inside a sprint — as a one-day activity crammed between other ceremonies — typically get a rushed session with incomplete attendance that produces a wall nobody refers to. The sessions need time and the right people. Give them both.
The Glossary follows — every major Event Storming term defined clearly.
Every major term used in this guide, defined plainly. Where a term connects directly to a DDD concept from the companion guide, that connection is noted.
The person or role that issues a Command. Represented on a small pink sticky note attached to the Command it triggers. Actors make explicit who is responsible for initiating each action in the process — and where automation could replace human action. Corresponds to the concept of a user role in the system design.
The domain object that receives a Command and produces a Domain Event. Represented on a yellow sticky placed between the Command and the Event in Design Level sessions. Maps directly to the DDD Aggregate concept — the cluster of domain objects that enforces business rules and maintains consistency. See the DDD companion guide, Chapter 8.
The strategic variant of Event Storming. Covers an entire business domain at high altitude, with a wide audience of domain experts and technical participants. Produces a domain-wide event timeline, hotspot map, and emerging context boundaries. Run at the start of significant projects or when the whole domain needs to be understood.
The natural boundary that emerges from a Big Picture session — the zone where language, team, and business focus are consistent. Corresponds directly to the DDD Bounded Context. See the DDD companion guide, Chapter 4.
An instruction that triggers a Domain Event. Written in imperative form — PlaceOrder, ApproveReturn, IssueRefund. Represented on a blue sticky placed to the left of the event it produces. Commands can be rejected (the instruction might not succeed); Domain Events cannot (they record what already happened).
The technical variant of Event Storming. Translates a process model into a software model by adding Aggregates and Read Models to the Command-Event timeline. Run immediately before development begins on a specific feature or Bounded Context. The output is close to a software specification.
Something that happened in the business that the business cares about. Past tense. Business language. Represented on an orange sticky note — the dominant element of every Event Storming session. Corresponds directly to the DDD Domain Event. See the DDD companion guide, Chapter 9.
A collaborative workshop technique invented by Alberto Brandolini for rapidly exploring complex business domains. Brings domain experts and technical teams together to build a shared model of the domain expressed as a timeline of Domain Events. Available in three variants: Big Picture, Process Level, and Design Level.
A system outside the domain being modelled that interacts with it — a payment gateway, a logistics API, an ERP. Represented on a lilac sticky placed where the external system triggers or receives events. Makes integration points visible without conflating external systems with internal domain logic.
A problem, disagreement, area of uncertainty, or unanswered question identified during the session. Represented on a red sticky placed prominently on the wall. The density and location of Hotspots by the end of the session is a risk map — a visual representation of where the process is fragile, contested, or poorly understood.
An insight or improvement possibility that emerges during the session — a process that could be automated, a step that could be eliminated, a rule that seems to contradict the business's stated goals. Represented on a green sticky. Not part of the domain model; a byproduct of knowledgeable people looking at the whole picture together.
A sequence of events happening simultaneously with another sequence, represented on the wall by placing events above or below each other at the same horizontal position. Real business processes involve multiple parallel tracks — the logistics track, the finance track, the customer communication track — that may diverge after a pivotal event and reconverge later.
A Domain Event that marks a major business transition — where responsibility shifts, where a significant commitment is made, or where the nature of the process fundamentally changes. Pivotal events often align with Bounded Context boundaries and appear on the Context Map as key integration points.
An automatic reaction — something the system does when a Domain Event occurs, without human intervention. Represented on a purple sticky. Expressed as a rule: "Whenever X, then Y." Policies are where business logic lives and where the most valuable hidden rules surface during Event Storming sessions. Corresponds loosely to Domain Services and automated business rules in DDD.
The operational variant of Event Storming. Examines one specific business process in detail, adding Commands, Actors, and Policies to the event timeline. Run after a Big Picture session to explore priority processes before redesign or automation. Produces a complete model of the process including all edge cases and exception paths.
The information an Actor needs to make a decision before issuing a Command. Represented on a yellow sticky placed to the left of the Command that requires it. Defines the data requirements of the user interface or query layer — what the system must surface to the right person at the right moment.
The shared vocabulary that emerges from the naming discipline of Event Storming sessions. Every Command, Event, Policy, and Actor named during the session is a candidate term in the Ubiquitous Language of the Bounded Context being explored. See the DDD companion guide, Chapter 3.