Event Storming is an interactive workshop that helps teams quickly develop a shared understanding of a business domain. By mapping out events, developers and business experts bridge their expertise, building a shared mental model that is clear enough to drive the design of an automated system.
Take, for example, a financial service advisor. They understand the step-by-step process of opening an investment account, including key events that unfold. When paired with technical experts, this shared knowledge becomes a powerful tool for aligning software design with real-world processes.
The process is simple and flexible.
- Participants capture business events on a modelling surface, placing sticky notes on a wall.
- Events are arranged in a rough timeline, representing the sequence of real-world events over a window of time.
- The focus remains on clarity and collaboration. No strict methodology is required.
Event Storming begins with events, the undeniable facts of the business. Orange sticky notes represent these events. Even a simple linear flow of events starts to reveal the underlying business process. Hidden dependencies and key interactions become visible.
Below is an example of how Event Storming surfaces key questions, helping teams understand the business reality before writing any code.
The focus is on conversational understanding. As those conversations unfold, teams gradually shape a living causal flow of events ordered from left to right. That flow reflects a shared understanding of how the business actually works.
Event Storming works best when treated as an ongoing practice, integrated into the SDLC as a standard kickoff for any project above a certain scope. The goal is active participation and shared understanding. What follows introduces the core vocabulary and techniques. You can start using them right away, even on your own, when facing a new domain modelling challenge.
Events, policies, commands, and aggregates are the core building blocks that shape an event-stormed domain model. They are the foundation for modelling observable reflective systems that respond to change, preserve intent, and evolve safely over time.
Things happen. Not all of them are interesting, some may be worth recording but don’t provoke a reaction. The most interesting ones cause a reaction. Many systems need to react to interesting events. Often you need to know why a system reacts in the way it did.
Event Storming is fundamentally a sociotechnical exercise. Its purpose is developing a shared understanding between disciplines. Visual modelling and technical solutions are secondary outcomes. The primary outcome is communication. Carving out time, getting people together, and talking through the domain is the actual work. The sticky notes, the contact paper, and the colour-coded jargon all exist to serve that communication. The process iterates until all stakeholders share a common understanding of the system and its processes.
The approach starts by modelling the business domain through events and state transitions. We are designing the system as a series of cause-and-effect flows, grounded in real-world behaviour and aligned with the structure of CHAIN.
Events: The Foundation of Observable Systems
Observable systems need a record of the events that shaped that state over time. The causal chain must be preserved as part of the core system record. When state is derived from facts, we can trace the entire causal history of x and understand exactly how it became 1.
Facts → Events → Causal History → Current State
Events are the durable record of what has happened in a system, independent of when or where you query them. Every state transition, every business decision, and every downstream consequence can be traced back to one or more events.
A value is a thing that does not change. It is eternal. It is a fact.
Fowler, Hickey, and the CHAIN model converge on the same point. Systems that record facts about what happened, rather than overwriting state with what is currently true, can explain their own behaviour. The causal chain from intent to outcome is preserved in the event record itself. This is the foundation that the rest of the modelling process builds on. We identify the meaningful events in the domain, capture the reactions they trigger, and preserve the reasoning behind each transition.
In practice, modelling starts by identifying the important events within the domain. An event is a factual statement. Stock Purchased, Order Cancelled, and Account Frozen are all events. Each captures something meaningful that happened at a specific time, forming part of the system’s ongoing story.
The first job in an Event Storming session is to communicate with each other and arrive at a shared understanding of one question: how do we express this complex process as a linear stream of facts over time?
Everything else follows from that. Policies, commands, and aggregates all build on the foundation of agreed-upon facts. If the team cannot agree on what happened and in what order, structural modelling will not produce a coherent system.
Policies: Encoding Cause and Effect
Once we have an idea of what facts are important over time within a process we are modelling, it is time to think about cause and effect.
A policy defines how the system should respond whenever a specific event occurs. It follows a simple pattern.
“Whenever (event) happens, then (policy) dictates that (action) should happen.”
- The event is something that has already happened.
- The policy describes how the system should respond.
- The action is the reaction triggered by the policy.
For example:
“Whenever a new account is created, send an acknowledgment email.”
Policies capture cause-and-effect relationships in a system. They help us reason about business behaviour by defining clear responses to meaningful events.
Real modelling begins when experts start to debate and define the concrete cause-and-effect relationships within a system. Policies are where those debates happen.
In the stock trading domain, a workshop might reveal an event flow similar to the following:
- A client opened a new portfolio
- A client purchased shares of stock
- A client sold shares of stock
- A client closed their portfolio
As we analyse these events, we naturally uncover gaps in the process. For example, at first glance these two events seem logical:
Client opened a portfolioClient purchased shares of stock
But someone else may ask: “What did the client use to purchase the shares?”
This leads us to insert a missing event: Client added cash to portfolio.
At this point, we can define a policy that governs this expected behaviour:
“Whenever a client opens a portfolio, they must first add cash before purchasing shares.”
Event Storming is an iterative process. Policies emerge as we refine our understanding of the business. Over multiple sessions, we begin to recognize common policies that can be named and reused across different domains.
Commands: Intentions That Trigger Change
Commands serve as the triggers for a sequence of one or more events. In Event Storming, they are represented by blue sticky notes to signal future intent.
Commands and events differ in a fundamental way.
- Events are irrefutable statements about the past.
- Commands express intent for something to happen in the future.
Commands can be refuted. A command represents an intention, and the system may reject it under certain conditions. During Event Storming, we might start to ask ourselves: what conditions must be true for this command to succeed? What happens when those conditions are violated? These questions surface the business rules that will eventually need a structural home.
For example, consider a command to Sell Stock. If the client’s portfolio has sufficient shares, the system emits a Stock Sold event. If the client lacks the necessary shares, the system emits a Trade Order Rejected event instead. The portfolio’s share balance is the invariant. The aggregate that owns the portfolio is responsible for enforcing it. Events represent facts. Commands represent possibilities.
One of the most important purposes of an event storming workshop is modelling failure. Resilient systems account for all possible events that can stem from a command, including failure scenarios.
- Business operations encounter both success and failure.
- Failure states must be treated as first-class concerns.
- A system is only as resilient as its design.
Aggregates: Boundaries of Consistent State
As an Event Storming workshop progresses, logical groupings of state emerge naturally. An Account or a Portfolio are typical examples.
In Domain-Driven Design (DDD), an aggregate is a cluster of domain objects treated as a single unit, ensuring consistency within a defined boundary. Domain objects are values (facts). An aggregate is a collection of related values.
A Portfolio is a good example of an aggregate because it embodies state, and most people have a clear mental model of what a portfolio contains. A portfolio likely contains multiple stock positions, cash, a current market value, and other related data.
Beyond representing state, an aggregate defines a boundary of consistent state. It acts as a transactional boundary within the system. All changes within an aggregate must remain strongly consistent. Changes across aggregates can be eventually consistent.
Well-defined aggregates allow systems to scale effectively. A portfolio aggregate ensures its cash and stock positions remain consistent. Updates to related aggregates, like an account or transaction history read model, propagate asynchronously.
Aggregates process commands and generate events when significant activities occur. Commands can be directed to an aggregate. The aggregate can emit events in response.
An aggregate is:
- A uniquely identifiable collection of related state (even if two portfolios hold identical positions, each remains distinct)
- Addressable, meaning a unique aggregate can be located (a portfolio has a unique ID that allows it to be retrieved)
Summary: Building Blocks
Event Storming offers the following fundamental elements for composing complex systems from simple components.
| Concept | Description | Colour |
|---|---|---|
| Aggregate | A collection of objects treated as a single unit for data changes. A consistency boundary when designing event-driven systems. | Pale Yellow |
| Domain event | Something that has happened in a domain. May be published across bounded contexts. | Orange |
| Command | An action to be performed, often triggering one or more aggregate or domain events. | Blue |
| Issue | A problem or decision that needs to be addressed during the event storming session. | Hot Pink |
| Actor | A system or person that performs actions, triggering commands. | Yellow |
| Read model | A specialized model designed to answer specific queries, supporting different views of data. | Green |
| External system | A system outside the domain that interacts with it, often as a source or target. | Light Pink |
| Policy | Business rules or actions taken in response to events occurring in the system. | Lilac |
Event Storming is meant to be low fidelity. Most sessions can be highly productive with nothing more than commands, aggregates, and events. Start slow and light. Build up your intuition as you experience more success with the process. The goal is to encourage a light framework around important conversations across diverse stakeholders, not to produce a comprehensive technical diagram in one sitting.
When I host an Event Storming session, I bring a printed legend with every sticky note colour we will be using and a brief explanation of what each one represents. That small investment in preparation makes the session accessible to everyone in the room, including participants who have never seen an Event Storming wall before.
Event Storming helps us build flows of cause and effect using simple, collaborative techniques. The next step is to turn these flows into a system structure using Domain-Driven Design.