Production engineering guide for event storming workshops covering patterns, implementation strategies, and operational best practices.
Event storming is a collaborative workshop technique for discovering and modeling domain events in complex business processes. It works best when teams need to understand how information flows through a system, particularly during early design phases or when refactoring existing systems.
The session requires 3-8 participants with domain knowledge. Typically include:
Use large sticky notes (at least 3"x3") and markers in multiple colors. Arrange space for a central wall or table where all participants can see everything.
Begin with a single business process or bounded context. Write the process start event on a yellow sticky note at the top of the wall.
Events should be named in past tense and describe what happened, not what is happening. Examples:
Create separate sticky notes for:
Place events horizontally across the wall, ordered chronologically from left to right. The timeline should be readable from left to right.
Create sticky notes for each actor or system involved in the process:
When an actor initiates a process, create a command event (blue) and place it on the timeline. The command should be followed by the resulting domain event.
Identify business entities that encapsulate related data and behavior. These become aggregate root names:
For each domain event, determine what command caused it. For example:
Create separate sticky notes for read models that consumers need to understand the system state.
Events flow from left to right in chronological order. Each event should have a clear causal relationship to the next.
Multiple events can happen simultaneously, shown by placing them on the same horizontal line.
Add decision points with "if" conditions on sticky notes. These typically result in branching timelines.
Creating too many granular events leads to complexity. Focus on meaningful business facts rather than implementation details.
Only creating domain events without identifying the commands that trigger them makes the flow incomplete.
Mixing up domain events, command events, and system events creates confusion about causality.
When multiple aggregates are involved in a process, create separate timelines for each aggregate and connect them with arrows or shared events.
Create dedicated sticky notes for external systems or services. Mark these as "external" or "third-party".
Add error events and recovery steps to the timeline. These should be clearly marked and positioned appropriately in the flow.
While physical sticky notes are preferred, use digital tools like Miro or Mural for:
When the timeline becomes too complex, participants lose track of causality. To prevent this, keep each event on a single horizontal line.
Participants often create events for every possible system action rather than focusing on business-relevant facts.
Failing to identify all actors involved in a process leads to incomplete models.
A typical session lasts 2-4 hours. Break into 30-minute segments with breaks between each major phase.
Use a timer and rotate facilitation roles. Keep the group focused on events, not technical details.
When conflicts arise about event naming or flow, use voting or consensus techniques.
Convert the sticky notes into formal documentation:
Store the final model in a version-controlled repository. Use clear file names like event-model-order-processing.md.
Distribute the final timeline to all participants and stakeholders. Create a summary of key events and their relationships.
Events should be stored with timestamps and metadata for audit purposes.
Ensure chronological ordering is maintained when implementing event handling systems.
Define consistent schemas for all events, including required fields and data types.
Using inconsistent naming conventions leads to confusion. Stick to past-tense verbs and clear business semantics.
Failing to include timestamps, causality markers, or source information makes events difficult to trace.
Missing relationships between commands and events creates gaps in understanding the system behavior.
The final model provides a shared understanding of business processes and their flow.
The event storming session produces concrete examples for technical design decisions.
The visual model becomes a communication tool for both technical and non-technical stakeholders.
As requirements change, update the event storming model accordingly. Document changes with clear commit messages.
Schedule periodic reviews of the event model to ensure it remains accurate as the system evolves.
Use the event model to analyze how changes affect other parts of the system.
This page was rewritten on 15 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy