| name | event-storming |
| description | Use when someone is starting a new product, untangling a legacy system, mapping how a business process actually works, or asking where to begin domain modeling — even if they do not name Event Storming explicitly. Triggers on: "domain modeling", |
| scenarios | ["We're starting a new product and need to model the domain before writing code","Help me run an event storming workshop to discover bounded contexts","We need to understand our business domain events before designing the system","새 프로덕트 개발 전에 도메인 모델링을 해야 해","이벤트 스토밍 워크샵을 진행해줘"] |
| compatibility | {"recommended":["think-tool","sequential-thinking"],"optional":[],"remote_mcp_note":"think-tool이 있으면 바운디드 컨텍스트 경계 분석을 더 깊이 수행합니다. sequential-thinking은 Big Picture → Process Level → Design Level 순서를 강제합니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
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-architect or spring-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
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
