Event Storming is a collaborative workshop technique used in Domain-Driven Design (DDD) to explore complex business domains and to develop a shared understanding among stakeholders, including domain experts, developers, and architects. Event Storming helps to identify and define domain events, business processes, and user interactions visually and interactively.
Event Storming can be used as a precursor to software development or during the software development process to refine the domain model and to identify areas where the software design can be improved. In addition, it can uncover hidden assumptions and misunderstandings and encourage collaboration and communication among team members.
Overall, Event Storming is a powerful technique for understanding complex business domains and developing a shared mental model that can guide software development efforts in a way that reflects the business domain.
Here are some notes based on the whole day event storming workshops.
Start with a short definition: Event Storming is a rapid design technique that engages domain experts, architects and developers. Elaborate in case of questions.
It is essential to remember that the main focus is on business processes and not nouns and DB models. It can take a lot of work to switch ways of thinking for technical people.
Whole Event Storming consists of different parts:
Definition of domain events (average 2–3h)
- We start with a blank paper wall with an arrow from left to right representing a timeline.
- Everybody is standing in the front, not sitting (remove tables and chairs)
- Everybody has a pad of sticky notes and a pen.
- Sticky notes are in orange in this part.
- It would be best if you also had a pad of sticky notes in red. Use them to mark inconsistencies or essential things needing more time/analysis later.
- Events are in past form, e.g., “New account registered”.
- Write events and put them on a timeline.
- It is better to write about too many events than too little.
- Ask and start a discussion if needed.
- If duplicates got spotted or some events do not look relevant anymore, throw them away.
- One person from the group goes through all events from left to right and describes the timeline to the rest of the group. Remove duplicates and reorganise if needed.
- Add more events if needed.
- Repeat going through the timeline with different participants. All other participants should listen. When everybody tells the same story, proceed to the next step.
Define commands (1h)
- Commands cause one or many Domain Events, e.g. “register account.”
- Sticky notes are in light blue in this part.
- Locate a sticky note before the Domain Event.
- Use a bright yellow sticky note for the role if it can be defined and place it on the left bottom command corner.
Define aggregates (1h)
- Aggregate words can be too abstract for all. Synonyms are data and entity.
- sticky notes er in light yellow
- place between command and Event in a bit more up
Define boundaries
- group sticky notes in defined boundaries
- connect them with arrows to show flow on the modelling surface
Based on experience, that is all you can do in one day. This kind of workshop drains people from the energy. For more information, look up Domain-Driven Design Distilled — Vaughn Vernon.
If you need help organising an Event Storming session, check out https://flowlab.no. We offer resources and support to help you get started so that you can have a successful and productive workshop with your team.
- Domain-Driven Design Distilled — Vaughn Vernon
