This text is based on a talk by Alberto Brandolini that he gave at DDD Europe 2019, watch the full video.
A Guide to this Collaborative Modelling Method
If you've ever sat through a requirements meeting where everyone left with a different understanding of the problem, you already know why EventStorming exists.
Created by Alberto Brandolini, EventStorming is a collaborative workshop technique designed to bring together the people who understand the business and the people who build the software, and get them modelling together on the same wall. It sounds deceptively simple. The results are anything but ordinary.
The Problem EventStorming Solves
Most organisations carry a hidden assumption: that domain experts understand the whole business. In reality, they don't. They understand their silo, often brilliantly, but the knowledge of how things connect across the organisation is fragmented, inconsistent, and in some places simply missing, especially wherever someone has left the company.
This fragmentation is precisely why so much enterprise software misses the mark. Developers are not translating clear requirements into code. They are translating incomplete, silo-bound knowledge into software, and that is a fundamentally different problem.
EventStorming doesn't try to paper over this gap with better documentation. It makes the gap visible, on a wall, in a room, with everyone present.
The Big Picture Format
The largest EventStorming format, known as Big Picture EventStorming, starts by inviting the right people: business representatives, IT staff, UX designers, product managers, and, where possible, actual customers. Groups of 20 or more are entirely normal for this format.
Participants work on a long roll of paper, modelling everything that happens in the business flow using sticky notes. The key building block is the domain event, written in the past tense on an orange sticky note. "Order placed." "Payment confirmed." "Item dispatched."
Why past tense? Because it forces precision. A past-tense event describes a specific moment in time, a state transition, something that actually happened and that might trigger what comes next. It is naturally concrete, and it anchors the conversation in shared reality rather than vague intentions.
At the start, the process is deliberately chaotic. Participants place their sticky notes independently, each capturing what they know. Then comes the harder work: connecting those events into a causal timeline, left to right. It is in this step that differences of opinion surface. Disagreements, contradictions, and blind spots get captured too, with comments, questions, and hotspot markers.
By the end of a Big Picture session, the whole business flow is visible on 12 to 18 metres of wall. Brandolini notes, with characteristic wit, that if your organisation needs more than 18 metres, the market will eventually sort that out for you.
The real value is twofold: everyone is forced to understand what happens in other parts of the organisation, and the group reaches both understanding and political consensus around the core problem, often in a single day.
From Big Picture to Process Modelling
Once the main bottleneck or core challenge has been identified, EventStorming shifts to a smaller, more focused format: Process Modelling.
Here the grammar becomes richer. The orange domain events remain central, but they are joined by:
- Commands (blue): decisions made by a user or system that trigger something
- Policies (lilac): the rules or habits that connect an event to the next command
- Read models (green): the information a user needs in order to make a decision
- External systems (pink): third-party services or organisational boundaries that constrain what you can do
Policies are where things get interesting. Between every event and every command, there is a decision. Sometimes that decision is obvious. Sometimes it reveals enormous complexity that nobody had articulated before. Brandolini suggests two useful questions to stress-test any policy: does this happen immediately? Does it happen always? The answers frequently rewrite what everyone thought they understood.
Software Design and Bounded Contexts
The third level of EventStorming moves into software design, where the focus shifts to aggregates, state machines, and the precise boundaries of your domain model. This is deliberately kept separate from the earlier stages, because forcing non-technical participants to reason about aggregates is counterproductive. The business people understand value; aggregates are your problem.
What EventStorming reveals across all three levels is where the natural bounded contexts sit. As participants take ownership of different sections of the model, saying in effect "this is my territory," the boundaries become visible organically. Different people need different models of the same concept. An online shop preparing a product for the catalogue needs rich detail. The team referencing that product in a promotional campaign does not. Those are two different models, and they belong in two different bounded contexts.
Why Events Are the Right Language
One of the central insights is that domain events are the ideal connecting thread across all levels of this work. The same building block that works in a Big Picture workshop also works in process modelling and software design. Events enable storytelling, and storytelling is naturally consistent: no one wants to tell a story that doesn't make sense.
More fundamentally, an event-centric architecture allows you to model the same system from a business perspective, a process design perspective, and a software engineering perspective, all using the same notation. A data-centric approach cannot do this.
What You Leave the Room With
At the end of a well-run EventStorming session, you have:
- A shared understanding of the whole business flow, with no hidden areas
- A clear view of the most important problem to solve, with organisational consensus around it
- A set of candidate bounded contexts to guide your architecture
- A model precise enough to begin designing software with confidence
Brandolini describes the target state as the "Bruce Lee state": a point where your model feels so solid that you are actively welcoming new requirements, because you know your design can handle them.
Ready to Go Deeper?
EventStorming is part of the Domain-Driven Design toolkit. If you are working on complex software in complex domains, it may be the most valuable time you spend before writing a single line of code.
EventStorming is not a technique you fully learn by reading about it. It is learned by doing.