Event storming is a rapid, hands-on, and highly collaborative workshop-based methodology used to explore complex business domains. Developed by Alberto Brandolini, it facilitates a shared understanding between technical and business stakeholders by visually modeling the flow of events within a system or business process. It is particularly effective for understanding the "what happened" in a domain, making it a powerful tool for Domain-Driven Design (DDD), microservices architecture, and business process re-engineering.
Origins
Event storming was introduced by Alberto Brandolini in 2013 as a method to help development teams understand complex business logic quickly and effectively, especially in the context of Domain-Driven Design. It evolved from a need for a more dynamic and engaging alternative to traditional specification and modeling techniques.
Core Principles
The methodology is based on several core principles:
- Collaborative Learning: It brings together diverse perspectives (domain experts, developers, testers, UX designers) to create a collective understanding.
- Ubiquitous Language: It fosters the development of a shared language (the "Ubiquitous Language" from DDD) by focusing on terms and concepts understood by both business and technical participants.
- Visual Modeling: It uses a large modeling surface (typically a long paper roll or whiteboard) and different colored sticky notes to represent various elements of the domain, making the process tangible and easy to follow.
- Domain Events as the Core: The primary building block is the "domain event," which describes "something that happened" in the business.
- Chronological Flow: Events are arranged chronologically from left to right, creating a timeline of the business process.
- Hot Spot Identification: Areas of uncertainty, complexity, or disagreement are explicitly marked as "hot spots" for further discussion and investigation.
Key Elements and Notation
Event storming typically uses different colored sticky notes to represent various concepts:
- Orange Sticky Notes (Domain Events): The most crucial element, representing significant occurrences within the business domain (e.g., "Order Placed," "Payment Processed," "Item Shipped"). These are written in past tense.
- Blue Sticky Notes (Commands): Actions initiated by a user or an external system that lead to a domain event (e.g., "Place Order," "Process Payment").
- Yellow/Pink Sticky Notes (Aggregates/Read Models):
- Aggregates (Yellow): Clusters of related data and behavior that maintain a consistent state within a transaction boundary. An aggregate is responsible for executing commands and emitting domain events.
- Read Models/Views (Pink): Projections of data used for querying or displaying information to users (e.g., "Order Details Screen," "Customer Dashboard").
- Green Sticky Notes (Policies/Reactions): Rules or processes that react to a domain event by triggering subsequent commands or events (e.g., "When Order Placed, Allocate Stock").
- Purple Sticky Notes (External Systems/Actors): Represents systems or human actors outside the current domain that interact with it.
- Red Dots/Stickers (Hot Spots): Marks areas of uncertainty, contention, or significant complexity that require further discussion or investigation.
The Event Storming Process
An Event storming workshop typically involves the following steps:
- Preparation: A large modeling surface (a long paper roll on a wall is common), a supply of different colored sticky notes, markers, and a facilitator are prepared.
- "Big Picture" Event Storming (Optional but Recommended): Participants collaboratively identify all significant domain events across an entire value stream, arranged chronologically. This provides a high-level overview.
- "Process Level" Event Storming: A deep dive into a specific business process or bounded context identified during the big picture phase.
- Brainstorming Events: Participants start by placing orange sticky notes on the timeline, describing all relevant domain events.
- Connecting Events: Events are then connected with commands (blue) that trigger them, and policies (green) that react to them.
- Identifying Aggregates: Yellow sticky notes are used to identify the aggregates responsible for processing commands and emitting events.
- Adding External Systems/Actors: Purple sticky notes denote interactions with external systems or human actors.
- Marking Hot Spots: Red dots are used to highlight areas of confusion, contention, or complex logic.
- Refinement and Discussion: The model is iteratively refined, discussed, and challenged by all participants. The facilitator guides the conversation, ensuring clarity and consensus.
- Bounded Context Identification: Through the process, natural boundaries for different business capabilities (bounded contexts in DDD) often emerge.
- Next Steps: The output serves as a blueprint for further design, architecture, and implementation, often feeding into more detailed design activities or forming the basis for backlog creation.
Types of Event Storming Workshops
Brandolini identifies three main types of Event storming workshops, each with a different focus:
- Big Picture Event Storming: Focuses on the entire business value stream, identifying key events and high-level relationships to understand the business as a whole.
- Process Level Event Storming: Dives deeper into a specific business process, modeling the commands, events, aggregates, and policies within a single bounded context.
- Design Level Event Storming: Explores implementation details for a specific bounded context, often discussing code-level constructs and technical implications.
Benefits
- Shared Understanding: Creates a common mental model and ubiquitous language among all stakeholders.
- Rapid Domain Exploration: Allows for quick and efficient exploration of complex domains, often compressing weeks of analysis into days or hours.
- Early Risk Detection: Helps identify ambiguities, inconsistencies, and complex areas (hot spots) early in the development cycle.
- Improved Collaboration: Fosters cross-functional collaboration and breaks down silos between business and technical teams.
- Foundation for DDD: Provides an excellent starting point for applying Domain-Driven Design principles, especially for identifying aggregates, bounded contexts, and service boundaries.
- Architectural Insight: Illuminates potential microservice boundaries and event-driven architectures.
Limitations and Challenges
- Facilitator Skill: Requires a skilled facilitator to guide the process, manage discussions, and maintain focus.
- Participant Engagement: Requires active and engaged participation from all attendees, especially domain experts.
- Scope Management: For very large domains, it can be overwhelming if not properly scoped.
- Transition to Implementation: While excellent for discovery, the output needs to be translated into actionable design and implementation plans.
Relationship to Other Methodologies
- Domain-Driven Design (DDD): Event storming is highly complementary to DDD, serving as a powerful discovery tool for identifying aggregates, bounded contexts, and a ubiquitous language.
- Event Sourcing: The emphasis on domain events makes Event storming a natural fit for systems designed with an event-sourcing architecture.
- Value Stream Mapping: Shares similarities in visualizing a flow and identifying bottlenecks, but Event storming focuses more on events and domain logic.
- Business Process Modeling Notation (BPMN): While both model business processes, Event storming is more collaborative, agile, and focused on domain events rather than formal process definitions.