Event Storming

How event storming works

You run an event storming session as a facilitate workshop. Everyone participates, and the facilitator keeps the group focused and engaged, guiding progress towards a completed model of the domain. The group starts with domain events, walking thought the model forwards and backwards to ensure that everything is covered. Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external systems, and event time.

The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded contexts. Along the way, key test scenarios, users, and goals are identified and incorporated into the model. Finally, the relationships between bounded contexts are added to create a context map. The resulting model is then challenged with code in order to validate the group learning and verify the model.

When and where to use event storming

The most obvious time to use event storming is at a project,s inception, so the team can start with a common understanding of the domain model. Another high-payoff time to use event storming is as part of a project’s close, to capture and share what the team learned in the process of building the software. That’s important because no single developer is likely to know the entire domain due to incidental discovery., modification, and limited exposure to other areas. It’s also advantageous to use event storming on a smaller scale, such as when you’re thinking about changing something, starting a new story, or working out different scenarios or alternatives.