Event Storming: Collaborative Domain Discovery
Event Storming is a workshop-based technique for rapidly exploring complex business domains. Created by Alberto Brandolini, it brings together developers and domain experts to discover domain events, commands, aggregates, and bounded context boundaries.
TL;DR
| Aspect | Description |
|---|---|
| What | Workshop using sticky notes to explore domain |
| Who | Developers + domain experts + stakeholders |
| Duration | 2-4 hours for Big Picture, 1-2 days for Design Level |
| Output | Shared understanding, bounded contexts, aggregates |
Why Event Storming?
Traditional requirements gathering fails because:
- Documents get outdated
- Meetings are one-directional
- Developers don't understand the domain
- Domain experts don't understand technical constraints
Event Storming solves this by:
- Collaborative - Everyone contributes
- Visual - Sticky notes on a wall
- Fast - Discover in hours, not weeks
- Shared understanding - Same mental model
The Sticky Note Colors
Each color represents a different concept:
┌─────────────────────────────────────────────────────────┐
│ EVENT STORMING COLOR LEGEND │
├─────────────────────────────────────────────────────────┤
│ │
│ 🟧 ORANGE = Domain Event │
│ "Something that happened" (past tense) │
│ Examples: OrderPlaced, PaymentReceived │
│ │
│ 🟦 BLUE = Command │
│ "Intent to do something" (imperative) │
│ Examples: PlaceOrder, ProcessPayment │
│ │
│ 🟨 YELLOW = Aggregate / Entity │
│ "Thing that handles commands and emits events" │
│ Examples: Order, Payment, Customer │
│ │
│ 🟪 PURPLE / LILAC = Policy / Process │
│ "When X happens, then Y" (automation) │
│ Examples: "When OrderPlaced, reserve inventory" │
│ │
│ 🟩 GREEN = Read Model / View │
│ "Information needed to make decisions" │
│ Examples: OrderSummary, InventoryLevel │
│ │
│ 👤 SMALL YELLOW = Actor / User │
│ "Who triggers the command" │
│ Examples: Customer, Admin, System │
│ │
│ 🔴 RED / PINK = Hot Spot / Question │
│ "Problem, confusion, or needs discussion" │
│ Examples: "What if payment fails?" │
│ │
│ ⬜ WHITE = External System │
│ "System outside our boundary" │
│ Examples: Stripe, SendGrid, Legacy CRM │
│ │
└─────────────────────────────────────────────────────────┘
Workshop Types
1. Big Picture Event Storming
Goal: Understand the entire domain at a high level Duration: 2-4 hours Participants: 10-20 people (diverse roles) Output: Domain overview, hot spots, bounded context candidates
Process:
- Chaotic exploration (everyone adds events)
- Timeline enforcement (order events left to right)
- Identify pivotal events (major state changes)
- Mark hot spots (problems, questions)
- Group into bounded contexts
2. Process Modeling Event Storming
Goal: Model a specific business process Duration: Half day Participants: 5-10 people Output: Detailed process flow with commands, events, policies
3. Design Level Event Storming
Goal: Design aggregates and bounded contexts for implementation Duration: 1-2 days Participants: 3-7 people (mostly developers + 1-2 domain experts) Output: Aggregate boundaries, command handlers, event flows
Running a Big Picture Session
Preparation
Materials:
- Large wall or paper roll (8+ meters)
- Sticky notes (orange, blue, yellow, purple, pink, green)
- Markers (thick, dark colors)
- Tape
Participants:
- Domain experts (essential!)
- Developers
- Product managers
- UX designers
- Anyone who knows the domain
Rules to Announce:
- No wrong answers
- Use past tense for events
- One concept per sticky
- Write big and clear
- Questions are welcome (use pink stickies)
Phase 1: Chaotic Exploration (30-45 min)
"Write domain events - things that happen in the business.
Use past tense. One event per orange sticky.
Don't worry about order yet."
Facilitation tips:
- Start with an example: "OrderPlaced"
- Encourage domain experts to lead
- Developers should ask questions
- Capture everything, filter later
Example events discovered:
🟧 CustomerRegistered
🟧 OrderPlaced
🟧 PaymentReceived
🟧 PaymentFailed
🟧 OrderShipped
🟧 OrderDelivered
🟧 RefundRequested
🟧 RefundProcessed
🟧 InventoryReserved
🟧 InventoryDepleted
Phase 2: Timeline Enforcement (20-30 min)
"Now let's arrange events in order.
Time flows left to right.
Events that happen around the same time can be vertical."
Phase 3: Identify Pivotal Events (15 min)
"Which events represent major state changes?
These are 'pivotal events' that change everything after them."
Pivotal events (mark with vertical line or different border):
OrderPlaced- Starts the fulfillment processPaymentReceived- Enables shippingOrderShipped- Inventory committedOrderDelivered- Transaction complete
Phase 4: Add Commands and Actors (30 min)
"What triggers each event? Add blue command stickies.
Who performs the command? Add small yellow actor stickies."
👤 Customer
🟦 PlaceOrder
🟧 OrderPlaced
👤 System
🟦 ReserveInventory
🟧 InventoryReserved
👤 PaymentGateway
🟦 ConfirmPayment
🟧 PaymentReceived
Phase 5: Mark Hot Spots (15 min)
"Add pink stickies for:
- Questions we can't answer
- Disagreements
- Complex areas
- Missing information"
Example hot spots:
🔴 "What if payment fails after inventory reserved?"
🔴 "Who handles partial shipments?"
🔴 "How long do we hold inventory?"
🔴 "What's the refund policy?"
Phase 6: Identify Bounded Contexts (30 min)
"Look for natural groupings:
- Events that belong together
- Different languages/terms
- Different teams
- Different lifecycles"
Draw boundaries around related events:
Design Level Event Storming
After Big Picture, zoom into specific bounded contexts:
Add Aggregates (Yellow)
👤 Customer
🟦 PlaceOrder
🟨 Order (Aggregate)
🟧 OrderPlaced
Add Policies (Purple)
🟧 OrderPlaced
🟪 "When OrderPlaced, reserve inventory"
🟦 ReserveInventory
🟧 InventoryReserved
Add Read Models (Green)
🟩 ProductCatalog
(needed to place order)
👤 Customer
🟦 PlaceOrder
Complete Flow Example
┌─────────────────────────────────────────────────────────┐
│ DESIGN LEVEL: ORDER PLACEMENT FLOW │
├─────────────────────────────────────────────────────────┤
│ │
│ 🟩 ProductCatalog 🟩 ShoppingCart │
│ │ │ │
│ └───────┬───────────┘ │
│ │ │
│ ▼ │
│ 👤 Customer ──► 🟦 PlaceOrder ──► 🟨 Order │
│ │ │
│ ▼ │
│ 🟧 OrderPlaced │
│ │ │
│ ┌──────────────────┼──────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 🟪 ReserveStock 🟪 SendConfirmation 🟪 ChargePayment │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 🟦 Reserve 🟦 SendEmail 🟦 Charge │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 🟨 Inventory ⬜ SendGrid ⬜ Stripe │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 🟧 StockReserved 🟧 EmailSent 🟧 PaymentReceived │
│ │
└─────────────────────────────────────────────────────────┘
Facilitation Tips
Do's
✅ Invite the right people - Domain experts are essential ✅ Start with events - They're the most intuitive ✅ Encourage questions - Hot spots are valuable ✅ Keep it moving - Don't get stuck on details ✅ Take photos - Document the wall ✅ Follow up - Turn insights into action
Don'ts
❌ Don't let developers dominate - Domain experts should lead ❌ Don't debate implementation - Focus on business concepts ❌ Don't skip hot spots - They reveal important problems ❌ Don't expect perfection - It's exploration, not specification ❌ Don't rush to code - Understanding first
Common Problems
| Problem | Solution |
|---|---|
| Domain experts are quiet | Ask them to describe their daily work |
| Too many events | Focus on one process at a time |
| Disagreements | Mark as hot spot, discuss later |
| Getting stuck | Move to another area, come back |
| Too technical | Redirect to business outcomes |
Remote Event Storming
For distributed teams:
Tools
- Miro - Most popular, great templates
- Mural - Good collaboration features
- FigJam - Figma's whiteboard
- Excalidraw - Simple, free
Adaptations
- Shorter sessions - 90 min max, multiple sessions
- Smaller groups - 5-8 people per session
- Clear facilitation - One person controls the board
- Breakout rooms - For parallel exploration
- Async prep - Share context before session
Remote Template
┌─────────────────────────────────────────────────────────┐
│ MIRO BOARD SETUP │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────────────────────────┐ │
│ │ LEGEND │ │ TIMELINE │ │
│ │ │ │ │ │
│ │ 🟧 Event │ │ ←── Past Future ──→ │ │
│ │ 🟦 Command │ │ │ │
│ │ 🟨 Aggregate│ │ │ │
│ │ 🟪 Policy │ │ │ │
│ │ 🔴 Hot Spot │ │ │ │
│ │ │ │ │ │
│ └─────────────┘ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PARKING LOT │ │
│ │ (Questions and ideas to discuss later) │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
From Event Storming to Code
Events → Domain Events
// From sticky: 🟧 OrderPlaced
public record OrderPlaced(
OrderId OrderId,
CustomerId CustomerId,
List<OrderLineItem> Items,
Money Total,
DateTime PlacedAt
) : IDomainEvent;
Commands → Command Handlers
// From sticky: 🟦 PlaceOrder
public record PlaceOrder(
CustomerId CustomerId,
List<OrderLineItem> Items
) : ICommand;
public class PlaceOrderHandler : ICommandHandler<PlaceOrder>
{
public async Task Handle(PlaceOrder command)
{
var order = Order.Place(command.CustomerId, command.Items);
await _repository.Save(order);
}
}
Aggregates → Domain Entities
// From sticky: 🟨 Order
public class Order : AggregateRoot
{
public OrderId Id { get; }
public CustomerId CustomerId { get; }
public List<OrderLine> Lines { get; }
public OrderStatus Status { get; private set; }
public static Order Place(CustomerId customerId, List<OrderLineItem> items)
{
var order = new Order(OrderId.New(), customerId);
foreach (var item in items)
{
order.AddLine(item);
}
order.AddDomainEvent(new OrderPlaced(...));
return order;
}
}
Policies → Event Handlers
// From sticky: 🟪 "When OrderPlaced, reserve inventory"
public class ReserveInventoryOnOrderPlaced : IEventHandler<OrderPlaced>
{
public async Task Handle(OrderPlaced @event)
{
foreach (var item in @event.Items)
{
await _inventoryService.Reserve(item.ProductId, item.Quantity);
}
}
}
Staff+ Interview Questions
Q: When would you use Event Storming vs other discovery techniques?
A: Event Storming is best when:
- Domain is complex and poorly understood
- Multiple stakeholders with different perspectives
- Need shared understanding quickly
- Want to discover bounded contexts
I'd use other techniques when:
- Domain is simple (just talk to experts)
- Remote-only with poor tooling (interviews might be better)
- Need detailed requirements (combine with user story mapping)
Q: How do you handle resistance from domain experts?
A: Common concerns and responses:
- "I don't have time" → "2 hours now saves weeks of rework"
- "I'm not technical" → "We need your business knowledge, not technical skills"
- "Just tell me what you need" → "We need to discover together what's possible"
Start small - a 1-hour session on one process. Success builds buy-in.
Q: How do you go from Event Storming to implementation?
A:
- Photograph everything - Document the wall
- Identify bounded contexts - From event clusters
- Prioritize - Which context to implement first
- Design level session - Zoom into priority context
- Extract aggregates - From yellow stickies
- Define events - From orange stickies
- Implement - Start with core aggregate
Quick Reference Card
┌─────────────────────────────────────────────────────────┐
│ EVENT STORMING QUICK REFERENCE │
├─────────────────────────────────────────────────────────┤
│ │
│ Colors: │
│ 🟧 Orange = Domain Event (past tense) │
│ 🟦 Blue = Command (imperative) │
│ 🟨 Yellow = Aggregate │
│ 🟪 Purple = Policy ("when X, then Y") │
│ 🔴 Pink = Hot Spot (question/problem) │
│ 🟩 Green = Read Model │
│ │
│ Big Picture (2-4 hours): │
│ 1. Chaotic exploration (events) │
│ 2. Timeline enforcement │
│ 3. Pivotal events │
│ 4. Commands and actors │
│ 5. Hot spots │
│ 6. Bounded contexts │
│ │
│ Key Rules: │
│ • Domain experts lead │
│ • Past tense for events │
│ • No wrong answers │
│ • Questions are valuable │
│ │
└─────────────────────────────────────────────────────────┘
Next Steps
- Domain Discovery - Other discovery techniques
- Aggregates - Implementing what you discovered
- Domain Events - Event design patterns