Event Storming cheat sheet
"its developer (mis)understanding that's released in production, not the experts' knowledge" Alberto Brandolini
What is it?
Event Storming is a flexible workshop format for collaborative exploration of complex business domains. It was created by Alberto Brandolini.
When to use it?
Event Storming can help you or your team learn more about the product. Doesn't matter if you are planning to build, currently building or planning a refactor. Here are some valid use cases:
If you're a tech lead or a manager
I'm onboarding new developers to the project
Event Storming wokrshop can help new developers get up to speed up processes and vocabulary used in the project
I'm starting new project with complicated business domain
Event Storming worksop can help understand the actors, processes and vocabulary
I want to map issues and improvements of current of current legacy system
You can start by mapping the current implementation and highlight the issues and painpoints. Then, you can host a separate session with the envisoned implementation. The main discovery goals are: domain language, observable system behaviours and hotspots
If you're a developer
I'm working on new complex feature or microservice
Hosting Event Storming session can boost the productivity and increase the correctness of code your team is planning to write.
I want to split monolith into microservice
In order to split your service into autonomous services you need to understand the areas of your systems. Workshop can help you identify the bounded contexts.
Elements
Event Storming uses different, named elements to model the domain. Because event storming is a flexible tehchnique you can add arrows, images or new elements depending on your needs. The colours of the cards and names might differ but the core elements are:
Actor
Actors represent groups of users interacting with the system.
Example actors for ridesharing application:
- • Driver
- • Rider
- • Moderator
Command
Definition
Command represents intention. Commands can be triggered by a user or an external system.
Examples
Example commands that could be made by an user:
- • Order product
- • Sign document
Insights
- • Commands can be mapped to POST, PATCH or PUT requests made to an API or messages published on the queue
Event
Definition
An event is a meaningful change that has happened in the past
Rules
There are general rules that you should follow when writing your events
Events should be written in past tense
Events are meaningful things that have happened in the past
Events should be specific
Events should be specific and not general. Many systems allow users to edit their profiles. Changing name often has a differnt consequences than changing your email or payment method.
This event is too general. It is better to have a separate event for each change. This makes it easier to understand what are the options and their consequences
Hotspot
Definition
Hotspots indicate need for future exploration. They can contain unknows or risks.
Examples
- • What is the recompensation strategy if order product is currently out of stock
Insights
- • The large number of hotspots may indicate that you are missing a key stakeholders or domain experts.
System
Definition
External systems which your system interacts with.
Examples
Some example systems include:
- • payment gateway
- • CRM (eg. SFDC)
- • Identity provider (Okta)
Insights
- • Number of external systems indicates the complexity of the system. The more integration there is the more complex the system
Event types
Events can operate on different abstraction and technical levels. It's important to know the differences. In most of the event storming sessions you should focus on discovering the domain events.
User Interface
Events related to touchpoints and interfaces
Domain
Meaningful business change
Environmental
Real world events. Can be added to increase visibility
Infrastructure
Low-level often implementation detail. Can be added if crucial domain part
Levels
Event Storming can be used on different levels of abstraction, depending on the goal of the workshop. Each level is a refinement of the previous and adds more details.
| Level | Elements | Goal |
|---|---|---|
| Big Picture Event Storming | Event, Hotspot, Actor, System | Get an overview of the domain |
| Process Level Event Storming | -||- plus Command, Policy, Read Model | Get an overview of the process |
| Design Level Event Storming | -||- plus Aggregate | Low level implementation based on tactical Domain Driven Design |
How to facilitate?
Universal tips that make a good facilitator also apply for facilitating an event storming workshop. However there are some specific tips that should make facilitating your next seesion more efficient:
General facilitation tips
- Start with a quick check-in
- Keep a timer and make breaks
- End with a check-out and collect feedback for next sessions
Introduce notation gradually
Don't overwhelm the team with too many elements at once. Start with events and add more elements only if they provide more clarity not confusion.
Pick a narrator
Pick a person who will look at the elements and explain whole flow to the rest of the team. People listenign could see what is missing and understand the flow better.
Session is as good as your events
Events are a key to a good outcome of the session. Make sure you spend enough time on discovering and refining them. Don't be tempted to "move on to next elements", this is not a game.
Create a dictionary for domain concepts
In a dedicated space write down all jargon, acronyms, or specialized terms that might be unfamiliar to participants.
Example modelling questions:
- who changes it?
- why does it change?
- can the change be repeated?
- can the change be withdrawn?
- how often does it change?
- what are the consequences of change?
What are the key requirements?
Provide unlimited modelling space
It can be a whiteboard, a wall, a flipchart, a digital board
Invite the right people
Developers, testers, designers (they bring the questions), domain experts (they bring the answers), facilitators
Levels
Big Picture Event Storming
This is the entry level session, with a goal to get an overview of the domain. The elements used during this section are: Event, Hotspot, Actor and System
Steps
1. Kick off
- • Describe workshop goal
- • Give an introduction to the technique
- • Have a clear definition of domain event
2. Chaotic exploration
- • Start with a first event
- • Let the participants generate events
3. Cleanup and refine events
- • Remove duplicates
- • Remove or rewrite events that don't follow the rules (see Event rules)
3. Enforcing the timeline
- • Add timeline to the board
- • Find the pivotal event
- • Move events on the timeline
4. People and systems
- • Identity actors in your system
- • Add actors to the board
- • Identity external systems
- • Add external systems to the board
5. Problems and opportunities
- • Go through the process in reverse, people cannot lie backwards. This may generate new events, improvements or branching
Last updated: 27.05.2025