Event Storming Advanced Skill
When to Use This Skill
Use this skill when:
-
Event Storming Advanced tasks - Working on deep dive event storming beyond big picture
-
Planning or design - Need guidance on Event Storming Advanced approaches
-
Best practices - Want to follow established patterns and standards
Overview
Conduct Event Storming sessions beyond big picture to process and design levels.
MANDATORY: Documentation-First Approach
Before facilitating Event Storming:
-
Invoke docs-management skill for Event Storming patterns
-
Verify methodology via MCP servers (perplexity)
-
Base guidance on Alberto Brandolini's methodology
Event Storming Levels
Event Storming Progression:
LEVEL 1: BIG PICTURE ├── Purpose: Understand the whole domain ├── Participants: Everyone (business + tech) ├── Output: Domain overview, hotspots, bounded contexts └── Duration: 2-4 hours
LEVEL 2: PROCESS LEVEL ├── Purpose: Detail specific business processes ├── Participants: Domain experts + analysts ├── Output: Detailed flows, policies, read models └── Duration: 2-4 hours per process
LEVEL 3: DESIGN LEVEL ├── Purpose: Translate to software design ├── Participants: Developers + architects ├── Output: Aggregates, commands, event handlers └── Duration: 2-4 hours per aggregate
LEVEL 4: SOFTWARE DESIGN ├── Purpose: Implementation details ├── Participants: Development team ├── Output: Code structure, APIs, schemas └── Duration: Ongoing
Sticky Note Colors
Standard Event Storming Palette:
🟠 ORANGE: Domain Events
- Things that happened
- Past tense naming
- Business-significant state changes
🟦 BLUE: Commands
- User intentions
- Imperative naming
- May be rejected
🟨 YELLOW: Actors/Users
- Who initiates commands
- Personas or roles
- External systems
🟪 PURPLE/PINK: Policies/Reactions
- Business rules
- "When X happens, we do Y"
- Automated responses
🟩 GREEN: Read Models
- Information needed
- Views/screens
- Query results
⬜ WHITE: External Systems
- Third-party integrations
- Legacy systems
- APIs we don't control
🔴 RED/PINK: Hot Spots
- Questions
- Conflicts
- Areas of uncertainty
Big Picture Event Storming
Purpose and Outcomes
Big Picture Goals:
- Create shared understanding
- Discover bounded contexts
- Identify hot spots and risks
- Find key domain events
- Align business and technical teams
What You Get:
- Timeline of domain events
- Bounded context candidates
- List of questions to answer
- Key actors and systems
- Critical business processes
Facilitation Steps
Big Picture Process:
STEP 1: CHAOTIC EXPLORATION (30 min)
- Everyone writes domain events
- No wrong answers
- Encourage wild ideas
- Cover the whole domain
STEP 2: TIMELINE ENFORCEMENT (30 min)
- Arrange events chronologically
- Left = earlier, right = later
- Find parallel flows
- Identify pivotal events
STEP 3: PIVOTAL EVENTS (20 min)
- Mark key moments (larger stickies)
- Business-critical transitions
- Points of no return
- Natural process boundaries
STEP 4: SWIMLANES (20 min)
- Group by actor or bounded context
- Identify handoffs
- Find integration points
- Note context boundaries
STEP 5: HOTSPOTS (20 min)
- Mark areas of confusion (red)
- Note missing information
- Flag conflicting views
- Capture open questions
STEP 6: BOUNDED CONTEXT SKETCH (20 min)
- Draw boundaries around related events
- Name the contexts
- Identify core vs supporting
- Note context relationships
Process Level Event Storming
Purpose and Depth
Process Level Goals:
- Detail one business process end-to-end
- Identify all commands and events
- Map policies and reactions
- Define read models needed
- Clarify business rules
Prerequisites:
- Big picture completed
- Process scope selected
- Domain experts available
- Questions from big picture
Extended Notation
Process Level Additions:
COMMANDS (Blue) ┌────────────────┐ │ CreateOrder │ │ ───────────── │ │ By: Customer │ └────────────────┘
POLICIES (Purple) - aka Reactions ┌────────────────┐ │ ⚡ When order │ │ placed, reserve│ │ inventory │ └────────────────┘
READ MODELS (Green) ┌────────────────┐ │ 📖 Product │ │ Catalog │ │ (shows price, │ │ availability) │ └────────────────┘
AGGREGATE (Yellow border) ┏━━━━━━━━━━━━━━━━┓ ┃ Order ┃ ┃ ┌────────────┐ ┃ ┃ │ OrderPlaced│ ┃ ┃ │ OrderPaid │ ┃ ┃ └────────────┘ ┃ ┗━━━━━━━━━━━━━━━━┛
Process Level Template
Process Level: [Process Name]
Scope
[What this process covers, start and end points]
Actors
- [Actor 1]: [Role description]
- [Actor 2]: [Role description]
Process Flow
[ASCII flow diagram]
Commands
Command
Actor
Event Produced
Preconditions
[Name]
[Who]
[Event]
[What must be true]
Events
Event
Command/Policy
Downstream Effects
[Name]
[Trigger]
[What happens next]
Policies
Policy
Trigger Event
Action
Produces
[Name]
[When this]
[Do this]
[Events/Effects]
Read Models
Read Model
Purpose
Populated By
[Name]
[What query]
[Events]
External Systems
System
Integration Point
Direction
[Name]
[Where]
Inbound/Outbound
Hot Spots & Questions
- [Question needing resolution]
- [Uncertainty to investigate]
Design Level Event Storming
Purpose and Artifacts
Design Level Goals:
1. Define aggregate boundaries
2. Identify command handlers
3. Design event structure
4. Specify validation rules
5. Plan event sourcing strategy
Outputs:
- Aggregate definitions
- Command/event schemas
- Invariant specifications
- Consistency boundaries
Aggregate Identification
Aggregate Design Questions:
BOUNDARY IDENTIFICATION:
- What must be consistent together?
- What can be eventually consistent?
- What is the transaction boundary?
NAMING:
- What noun represents this cluster?
- Is it a domain concept?
- Does business recognize it?
INVARIANTS:
- What rules must always hold?
- What combinations are invalid?
- What constraints protect integrity?
LIFECYCLE:
- How is it created?
- How does it change?
- When is it complete/archived?
Design Level Notation
Aggregate Card:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ AGGREGATE: Order ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Commands: ┃
┃ • PlaceOrder ┃
┃ • AddItem ┃
┃ • RemoveItem ┃
┃ • SubmitPayment ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Events: ┃
┃ • OrderCreated ┃
┃ • ItemAdded ┃
┃ • ItemRemoved ┃
┃ • OrderPaid ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Invariants: ┃
┃ • Total > 0 ┃
┃ • Items not empty ┃
┃ • Status valid transition ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Bounded Context Discovery
Context Mapping from Events
Finding Bounded Contexts:
LINGUISTIC BOUNDARIES:
- Where does terminology change?
- Where are there synonyms/homonyms?
- Where do meanings differ?
OWNERSHIP BOUNDARIES:
- Who owns which events?
- Where do teams hand off?
- Which group decides?
LIFECYCLE BOUNDARIES:
- Different rates of change?
- Different deployment needs?
- Different data governance?
TECHNICAL BOUNDARIES:
- Different tech stacks?
- Different scalability needs?
- Different consistency needs?
Context Relationship Patterns
Context Relationships:
PARTNERSHIP
[Context A] ◄──► [Context B]
Tight collaboration, shared goals
CUSTOMER-SUPPLIER
[Customer] ◄── [Supplier]
Supplier serves customer needs
CONFORMIST
[Conformist] ──► [Upstream]
Downstream conforms to upstream
ANTI-CORRUPTION LAYER (ACL)
[Context] ──[ACL]──► [Legacy]
Translation layer protects domain
OPEN HOST SERVICE (OHS)
[Provider] ──[OHS]──► [Many Consumers]
Published API for integration
SHARED KERNEL
[Context A] ◄──[Shared]──► [Context B]
Small shared code/model (use sparingly)
Workshop Facilitation
Room Setup
Physical Requirements:
- Long wall (8+ meters ideal)
- Plenty of sticky notes (all colors)
- Markers for everyone
- Tape or sticky wall
- Timer visible to all
- Refreshments available
Virtual Alternatives:
- Miro / Mural / FigJam
- Unlimited canvas
- Sticky note templates
- Timer integration
- Breakout rooms for parallel work
Facilitation Tips
Effective Facilitation:
DO:
✓ Keep energy high
✓ Enforce timeline direction
✓ Encourage questions
✓ Capture hot spots immediately
✓ Rotate facilitation if long session
✓ Take breaks every 90 minutes
✓ Photograph results frequently
DON'T:
✗ Let one person dominate
✗ Jump to solutions
✗ Ignore quiet participants
✗ Skip hot spot discussion
✗ Allow technology discussion too early
✗ Forget to capture decisions
Workflow
When conducting Event Storming:
- Prepare: Room, materials, participants, scope
- Big Picture: Domain-wide event exploration
- Identify Hotspots: Mark uncertainties and conflicts
- Find Boundaries: Sketch bounded contexts
- Select Focus: Choose process for deep dive
- Process Level: Detail commands, policies, read models
- Design Level: Define aggregates and invariants
- Document: Capture results in structured format
- Iterate: Refine based on implementation feedback
References
For detailed guidance:
Last Updated: 2025-12-26