The most expensive software mistakes come from building the wrong model of the business. The code works, the tests pass, and it does not match how the domain actually operates — so every subsequent change fights the model, and the cost compounds for years.
Event storming addresses this before any code exists, by getting the people who understand the domain and the people who will build the software to construct one shared picture.
What changed in 2026
- Remote sessions became normal. Virtual whiteboarding matured enough that distributed teams run sessions effectively, though in-person retains an advantage for the messier early phase.
- Sessions got shorter and more frequent. Multi-day workshops gave way to focused sessions on specific subdomains, which is easier to schedule and less exhausting.
- AI assistance appeared in synthesis. Automated clustering and summarization of session output reduced the tedious write-up phase.
- The anti-pattern got named. Running sessions without domain experts, producing a model of engineering assumptions, became widely recognized as the main failure mode.
How a session runs
| Phase |
Activity |
Output |
| 1. Chaotic exploration |
Everyone writes domain events on notes, in past tense |
A wall of unordered events |
| 2. Timeline |
Arrange events in rough chronological order |
A sequence with gaps and duplicates |
| 3. Pain points |
Mark where things go wrong or people disagree |
The list of real complexity |
| 4. Commands and actors |
Identify what triggers each event and who does it |
Cause and responsibility |
| 5. Aggregates |
Group events around the things that own them |
Candidate model objects |
| 6. Bounded contexts |
Draw boundaries where language changes meaning |
Candidate service boundaries |
Phase one produces chaos deliberately. Everyone writes events simultaneously without discussion, which surfaces the full breadth of the domain before anyone starts organizing it. Events are written in past tense — order placed, payment captured, shipment dispatched — because that keeps the focus on what happens rather than on what a system does.
Phase three is where the value concentrates. When two domain experts disagree about what happens, or when nobody can explain what happens between two events, you have found the part of the domain that will produce the most bugs. Those disagreements are the reason to run the session at all.
Phase six is where language matters. When the same word means different things to different people — an order to sales is not an order to fulfilment — that is a boundary. Naming it explicitly is what prevents a single overloaded model that satisfies nobody, which is the concern behind DDD aggregates explained.
What makes it work
Domain experts in the room, not represented by proxy. A session of engineers modelling their understanding produces a confident model of their misunderstandings.
Unlimited space and unlimited notes. Constraining the surface constrains the model, and the early phase needs room to be messy.
No solutioning during the domain phases. The instinct to jump to how it will be built kills the exploration, and it can be redirected without much difficulty by parking technical questions visibly for later.
A facilitator who keeps the timeline moving. Sessions stall in phase two, arguing about the exact ordering of two events that do not matter.
Capture and follow through. A photographed wall that nobody transcribes produces nothing. The output should become a written model, and the decisions it drives should be recorded — which is what architecture decision records are for.
Common mistakes
- No domain experts. Models the engineers' assumptions.
- Designing the solution during discovery. Kills the exploration.
- Skipping the chaotic phase. Organized too early means narrow coverage.
- Ignoring disagreements. They are the output, not an obstacle.
- No follow-through. A photograph of a wall is not a model.
- Trying to cover everything in one session. Focus on one subdomain at a time.
FAQ
How long does a session take?
A focused subdomain fits in a few hours. A whole complex domain takes several sessions rather than one long one.
Does it work remotely?
Yes, with virtual whiteboarding, and the chaotic phase benefits from being in one room. Hybrid sessions are the hardest to run well.
Who should attend?
Domain experts, engineers who will build it, and someone who can decide. Small enough that everyone participates.
What if the domain is already built?
Event storming on an existing system is useful for surfacing where the code model and the domain model have diverged.
Where to go next
For the modelling concepts, read DDD aggregates explained. For diagramming the result, the C4 model explained, and for recording decisions, architecture decision records.