newkayak12 Event Storming Facilitation
When to Use / When Not to Use
Use when:
- Starting a new product and need to discover bounded contexts
- Auditing or untangling a legacy system
- Aligning engineers with domain experts before writing code
- Asking "where should our service boundaries be?"
Do not use when:
- You need implementation code — run Event Storming first, then use
microservices-architectorspring-boot-engineer - The domain is already well-modeled and stable
Process
Level 1: Big Picture (2–4 hours)
Goal: Explore the entire business domain; discover bounded contexts and pain points.
- Invite 6–10 people: at least two domain experts and two developers
- Storm domain events freely (orange stickies, past tense): "What happens in this business?"
- Enforce past tense: "Order Placed", not "Order is placed"
- Cluster the timeline — related events hint at bounded contexts
- Mark red hotspots where experts disagree or language shifts
- Name the clusters — these are candidate bounded contexts
Level 2: Process Level (2–3 hours)
Goal: Add commands, actors, and policies to understand who triggers what and why.
For each orange event:
- Ask "What caused this?" → blue Command to the left
- Ask "Who issued this command?" → yellow Actor above
- Ask "Is this triggered by a rule?" → lilac Policy between event and command
- Ask "What does the actor need to see?" → pink Read Model to the left
- Where commands cross system boundaries → white External System
Reading flow (left to right):
[Read Model] → [Actor] → [Command] → [Policy] → [Domain Event]
Level 3: Design Level (2–4 hours, per bounded context)
Goal: Identify aggregates, define APIs, prepare for implementation.
- Group event/command pairs by aggregate (which commands target the same state machine?)
- Name each aggregate using the bounded context's ubiquitous language
- Define context boundaries: which events cross from one context to another? (integration events)
- For each aggregate: list invariants, state transitions, and commands handled
- Identify eventually-consistent aggregates → candidates for Saga or Outbox pattern
Output Template
After the workshop, document each bounded context:
Bounded Context: [Name]
Ubiquitous Language: [key terms and their definitions]
Commands: [list of commands handled]
Domain Events: [list of events emitted]
Integration Events (published): [events other contexts listen to]
Aggregates: [name, invariants, state transitions]
External Dependencies: [other contexts or systems consumed]
Hotspots Remaining: [open questions]
What Claude Does / What You Do
| Claude | You |
|---|---|
| Facilitates question sequences for each sticky type | Gather domain experts and developers |
| Identifies bounded context candidate names | Confirm with domain experts using real business language |
| Spots red flag patterns (noun events, missing actors) | Resolve hotspots with the actual stakeholders |
| Drafts the Bounded Context Output Template | Fill in from the actual workshop results |
| Recommends Design Level aggregate names | Validate invariants against real business rules |
Sticky Legend
| Color | Type | Naming Convention |
|---|---|---|
| Orange | Domain Event | Past tense: "Order Placed", "Payment Failed" |
| Blue | Command | Imperative: "Place Order", "Cancel Shipment" |
| Yellow | Actor / User | Role: "Customer", "Warehouse Clerk" |
| Lilac | Policy / Business Rule | "Whenever X, then Y" |
| Pink | Read Model / View | What the actor sees to decide |
| White | External System | Third-party name: "Stripe", "FedEx API" |
| White (wide) | Aggregate | Noun owning state and enforcing invariants |
| Red | Hotspot | Question or conflict — mark and move on |
Common Mistakes
| Mistake | Fix |
|---|---|
| Events named as nouns ("Order") | Enforce past-tense verbs: "Order Placed" |
| Only developers in the room | Require domain experts — they are the primary source |
| Skipping hotspots | Mark every disagreement; resolve after the session |
| Jumping to aggregates before events | Complete Level 1 and 2 before Level 3 |
| One person controlling the wall | Distribute stickies physically; anyone can place any sticky |
Facilitation Checklist
- Diverse participants: domain experts equal or outnumber developers
- Timer set per phase
- Red hotspot stickies available to everyone
- Photography or digital export taken at end of each phase
- Follow-up scheduled for hotspot resolution
Related Skills
microservices-architect— design service boundaries after bounded contexts are discoveredservice-boundary-validator— validate the boundaries against DDD and team topology principlestechnique-write:adr-writer— document key decisions that emerge from the workshopdomain-driven-design— deeper DDD concepts for aggregates and context mapping