Event Storming
A collaborative workshop technique for discovering domain events and designing event-driven systems.
Event Storming is a flexible workshop format created by Alberto Brandolini for rapidly exploring complex business domains. It brings together domain experts, developers, and stakeholders to discover domain events, understand business processes, and identify system boundaries through a collaborative, visual approach.
The technique uses colored sticky notes on a large modeling surface (typically a wall) to represent different elements of the domain, with orange sticky notes representing domain events as the central building block.
Shared Understanding
Brings technical and business people together to build a common understanding of the domain
Fast Discovery
Uncovers domain complexity quickly, often discovering insights in hours that would take weeks otherwise
Knowledge Sharing
Makes implicit domain knowledge explicit and shared across the entire team
Process Visualization
Reveals business processes, dependencies, and pain points in a visual, easy-to-understand format
Event Storming uses different colored sticky notes to represent different concepts:
Domain Events (Orange)
Something that happened in the domain. Always in past tense. Examples: OrderPlaced, PaymentReceived, UserRegistered
Commands (Blue)
An intention or decision to do something. In imperative form. Examples: PlaceOrder, ProcessPayment, RegisterUser
Aggregates (Yellow)
Entities or concepts that handle commands and produce events. Examples: Order, Payment, User Account
Policies/Reactions (Lilac)
Automated reactions to events. "Whenever X happens, then Y". Examples: When OrderPlaced ReserveInventory
Read Models (Green)
Information needed to make decisions. Data views used by actors or systems. Examples: Product Catalog, Customer Profile
External Systems (Pink)
Third-party systems or integrations. Examples: Payment Gateway, Email Service, Shipping Provider
Hot Spots (Red/Issues)
Problems, questions, or areas of concern that need resolution. Used to flag discussion points
Actors (Gray/Small Yellow)
People or systems that trigger commands. Examples: Customer, Administrator, Automated System
1Chaotic Exploration
Everyone writes domain events (orange stickies) independently and places them on the timeline. No talking yet - just rapid event generation.
Goal: Generate as many events as possible without overthinking
2Enforce Timeline
As a group, arrange events in chronological order from left to right. Identify duplicates, resolve naming conflicts, and ensure temporal consistency.
Goal: Create a coherent narrative flow
3Add Commands
Identify what actions (commands) trigger each event. Place blue stickies before the events they cause.
Goal: Understand what triggers each event
4Identify Aggregates
Group related commands and events around aggregates (yellow stickies). These become your consistency boundaries.
Goal: Define system boundaries and aggregate responsibilities
5Add Supporting Elements
Fill in policies, read models, actors, and external systems. Mark hot spots where there are questions or concerns.
Goal: Complete the picture with all necessary elements
6Identify Bounded Contexts
Draw boundaries around cohesive areas. These often become your microservices or modules.
Goal: Define logical system boundaries
Participants
- Domain Experts: Business stakeholders who understand the domain deeply
- Developers: Technical team members who will implement the system
- Facilitator: Someone to guide the process and keep things moving
- Optional: UX designers, product managers, operations staff
Materials Needed
- Large modeling surface (long wall, or multiple whiteboards)
- Sticky notes in multiple colors (orange, blue, yellow, lilac, green, pink, red)
- Markers for writing on stickies
- Tape or painter's tape to mark boundaries
- Camera or phone to document the results
Duration & Setting
- Full Workshop: 4-8 hours (can be split across multiple days)
- Space: Room with unlimited wall space and good lighting
- Group Size: 5-20 people (smaller is often better)
- •Analysis Paralysis: Don't overthink early stages. Get events on the wall first, refine later
- •Too Technical Too Soon: Focus on domain events before diving into implementation details
- •Dominant Voices: Ensure everyone participates, not just the loudest people in the room
- •Insufficient Space: Don't underestimate how much wall space you'll need - it always takes more than expected
- •Premature Optimization: Resist the urge to optimize or solve problems during discovery phase
- Rapidly explores complex domains in a matter of hours instead of weeks
- Creates shared understanding between business and technical stakeholders
- Reveals hidden complexity, dependencies, and potential issues early
- Provides a natural path to event-sourced system design
- Builds team alignment and collective ownership of the design