It’s a collaboration workshop to brainstorm, model a business process and share knowledge.
EventStorming sessions has a scope as a single business process that needs to be explored.
The process is explored as a series of domain events (sticky notes) over a timeline, and enhanced with additional concepts (actors, commands, external systems etc), until all of its elements tell the story how the business process works.
The session can take 2-4 hours.
All key people should participate. The more diverse, the better, because it leads to more knowledge discovered. It’s better to limit it maximum up to 10 people (5 for remote sessions).
Value of the EventStorming
At the end of the session you will have a model describing the business domain’s events, commands, aggregates, possible bounded contexts. But the real value is in the process itself:
- sharing knowledge among different stakeholders,
- alignment of their mental models of the business,
- discovery of conflicting models,
- formulation of the ubiquitous language.
When to use
Reasons to facilitate the EventStorming workshop:
- Build a ubiquitous language.
- Model the business process.
- Explore new business requirements.
- Recover domain knowledge.
- Explore ways to improve an existing business process.
- Onboard new team members.
When NOT to use it
If a process is simple/obvious, then the EventStorming will be less successful.
Legend
The EventStorming Process
What’s needed for EventStorming?
- Modeling space. A big wall covered with paper, large whiteboard etc.
- Sticky notes of different colors.
- Markers.
- Room.
Usually, there are 10 steps.
Step 1. Unstructured exploration
Brainstorm the domain events. They should be expressed in the past tense, because it’s something that already happened in the domain.
Orange sticky notes should be used for these.
No need to organize them at this step. Generate as much as you can, until there’s nothing coming into mind or the rate of adding new ones slows significantly.
Step 2. Timelines
Organize domain events in order in which they occur.
Start with the happy path scenario, then go to the alternative scenarios where errors may be encountered or different business decisions are taken.
Step 3. Pain Points
Mark the points that require attention (bottlenecks, manual steps that require automation, missing documentation, missing domain knowledge etc).
Use rotated (diamond) pink sticky notes.
Step 4. Pivotal Events
Look up for significant domain events that indicate a change in context or phase.
These pivotal events are an indicator of potential bounded context boundaries.
Step 5. Commands
Identify the commands that produce the domain events.
Commands is something that describes what triggered the event or flow of events. It should be written in the imperative form (“Publish campaign”, “Submit order”).
Use blue sticky notes to represent commands. Use small yellow sticky notes to represent actors
Step 6. Policies
Some commands will not have specific actors attached to them. It’s an indicator that possible automation policy should initiate this command.
An automation policy is a scenario in which an event triggers the execution of a command.
Use purple sticky notes to represent policies.
Policy may have a criteria that should be met. For example, only a complaint from a VIP customer can trigger an escalate command.
Step 7. Read Models
A read model is a view (GUI, report, notification) that actor uses to make a decision to execute a command.
It should be represented by green sticky note and positioned before the command.
Step 8. External Systems
Augment the models with external systems (systems that are not part of the domain). They can execute commands (input) or can be notified about events (output).
They should be represented by pink sticky notes.
It’s important that by the end of this step all commands should either be executed by actors, triggered by policies, or called by external systems.
Step 9. Aggregates
Organize related concepts in aggregates. It receives commands and produces events.
Represented by large yellow sticky notes with commands on the left and events on the right.
Step 10. Bounded Contexts
Look for aggregates that are related to each other (closely related functionality or coupled through policies).
Group of aggregates are possible bounded contexts.
