Event Storming
Use Event Storming when participants need a shared view of complex processes. The board structures discussion and makes uncertainty discussable.
- EventDomain events are ordered along a concrete case.
- QuestionDisputed terms and rules remain visible as open questions.
- ValidationAnother case lets domain experts test the process hypothesis.
Context
Why this is important
Explore domain event sequences collaboratively and derive model questions that can be validated.
A workshop format for domain exploration; facilitation, time-boxing and validation are part of its use.
From process to validated hypothesis
The shop case covers seven modules in one shared deployment. The payment provider remains external.
This is how you read the picture
- Event Event sequence
- Question Conflict marker
- Validation Case check
| Criterion | Step | Purpose |
|---|---|---|
| Board work | Order events | Record conflicts |
| Case check | State assumption | Validate flow |
Benefits & limitations
Helps if:
- Domain experts and developers need a shared view of a cross-functional process.
- Exceptions, state changes or terms are disputed across teams.
Boundaries
- An unclear exploration question or too many participants can overload the board; limit scope and time-box sections.
- Events remain modeling hypotheses until domain experts validate them; they do not automatically define technical module boundaries.
In practice
- Start from a concrete customer situation and invite people who know the flow and its exceptions. Agree on an exploration question for the session.
- Collect observable events in consistent past-tense wording. Keep disagreements visible and resolve them against a concrete case rather than by voting.
- Check the emerging flow hypothesis with a second scenario. Carry validated rules into the model and tests, and assign an owner to open questions.
Read the detailed explanation
The group places domain events in the past tense on a shared surface. It arranges them along a hypothesised flow, adds triggers, decisions and external participants, and marks contradictions. The board records observations and shows where the group is still forming hypotheses.
Facilitation uses concrete cases to check terms and rules: what condition triggers a step, what exception exists, and who can confirm a status? Validated findings inform the model, tests or architecture decisions. The workshop board itself does not set technical boundaries.
Validated terms inform the domain model; the team assesses possible boundaries as a Bounded Context.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which two events appear next to each other?
View the solution with justification
“Payment requested” and “payment authorised”.
ApplyingTransferred to a new situation
How would you explore a payment status that is initially missing?
View the solution with justification
Add events, participants and retry cases, then validate with domain experts.
EvaluateWeighing an alternative
When does the board establish a technical boundary?
View the solution with justification
The board alone does not; business rules and responsibilities need separate review.
Explore further
These building blocks continue the thoughts of this page.
References
- EventStorming · Official site (opens in new tab)Primary description of the collaborative workshop format.
- Alberto Brandolini · Introducing EventStorming (opens in new tab)Book by the creator with formats and facilitation guidance.
- Eric Evans · DDD Reference (opens in new tab)Reference on modeling and domain events.