Event Storming is a collaborative domain exploration workshop methodology invented by Alberto Brandolini. Through real-time sticky note collaboration across roles (domain experts + technical team), it models complex business domains in a short time, producing aggregates, bounded contexts, and domain events.
Workflow
6-Step Event Storming Workshop (about 2.5 hours):
- Step 1: Chaotic Exploration (30min) — Freely diverge and post all domain events (🟠 orange sticky notes)
- Step 2: Timeline Ordering (20min) — Arrange events in chronological order, identify the main line and branches
- Step 3: Key Event Marking (15min) — Mark the turning points of the business process (★ mark)
- Step 4: Commands and Roles (30min) — Complete the command + role for each event
- Step 5: Aggregate Discovery (30min) — Cluster related events into aggregates, name the aggregate roots
- Step 6: Bounded Context Division (20min) — Divide BCs by coupling degree, determine the context mapping
Outputs: Event timeline / Aggregate candidates / BC mapping / Hot Spots
Participating Roles: Domain experts (2-3 people) / Developers (2-3 people) / Product (1 person) / Architect (1 person)
When to Use
| Applicable Scenarios | Inapplicable Scenarios |
|---|---|
| New project kickoff, need domain modeling | Domain knowledge is fully documented, directly domain-designer |
| Existing system refactoring, business is unclear | Single-person development, no stakeholder participation |
| Cross-team collaboration, need a unified language | Pure technical tool development, no business domain |
| Microservice decomposition, need to determine service boundaries | Simple CRUD project, clear domain model |
Skill Boundary
| Skill | Positioning | When to Use |
|---|---|---|
ddd-event-storming |
Workshop facilitation + domain exploration | Early project phase, multi-role collaboration |
ddd-domain-designer |
Aggregate detailed design + code mapping | After the workshop, before development |
Audience
This skill is designed for: Backend developers (implementing DDD architectures), Software architects (evaluating and selecting patterns), Tech leads (reviewing team implementations), and DDD beginners (learning domain-driven design fundamentals).
6-Step Process Details
Step 1: Chaotic Exploration — 30 min
Participants freely diverge, using 🟠 orange sticky notes to post all known domain events (past-tense verbs, such as OrderPlaced).Discussion is prohibited—The facilitator must strictly enforce the "post first, talk later" principle.
活动: 自由贴出领域事件
格式: 动词过去式 (OrderPlaced, PaymentCompleted)
规则: 不讨论、不质疑、不排序
目标: 覆盖所有业务场景，包括异常流
Step 2: Timeline Ordering — 20 min
Arrange all 🟠 event sticky notes in chronological order, identify the main line and branches. Connect the main line with arrows, and branch exception flows off the main line with annotated conditions.
Step 3: Key Event Marking — 15 min
Mark the turning points of the business process; these are key events (★ mark), and are the core anchors of the domain model. Characteristics: trigger subsequent processes, change entity state, communicate across contexts.
Step 4: Commands and Roles — 30 min
Add 🔵 to each event blue commands(triggering actions) and 🟡 yellow roles(actors). Automatically triggered events also have command initiators (System, Scheduler, ExternalSystem).
👤 Customer → 🔵 Create Order → 🟠 OrderPlaced
👤 Admin → 🔵 Approve Refund → 🟠 RefundApproved
🤖 System → 🔵 Deduct Stock → 🟠 InventoryDeducted
Step 5: Aggregate Discovery — 30 min
Cluster related events and commands into aggregates, and name aggregate roots in business language. An aggregate is a transactional consistency boundary—strong consistency within the boundary, eventual consistency between boundaries.
┌─ Order Aggregate ────────────────────────┐
│ 🟠 OrderPlaced / 🟠 OrderPaid │
│ 🟠 OrderCancelled / 🟠 OrderCompleted │
│ 🔵 PlaceOrder / 🔵 PayOrder │
│ 👤 Customer │
│ 聚合根: Order | 不变式: 已取消不可支付 │
└──────────────────────────────────────────┘
Step 6: Bounded Context Division — 20 min
Draw BC boundaries based on the coupling between aggregates and changes in business language, and annotate the mapping relationships. Context mapping types: Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service.
Sticky Note Color Conventions
| Color | Meaning | Format Requirements | Example |
|---|---|---|---|
| 🟠 Orange | Domain Event | Past tense verb | OrderPaid, UserRegistered |
| 🔵 Blue | Command | Base form verb | PayOrder, RegisterUser |
| 🟡 Yellow | Actor/Role | Noun | Customer, System, Admin |
| 🟢 Green | Read Model | Noun | OrderDetailPage, Dashboard |
| 🔴 Pink | External System | System name | Alipay, WeChatPay |
| 🟣 Purple | Constraint/Hot Spot | Business rule statement | Max ¥50000 per order |
Workshop Outputs
Deliverables: Event Timeline (Mermaid sequence diagram), Aggregate Candidates, Bounded Context Map (Mermaid C4 diagram), Context Mapping, Hot Spot List, Ubiquitous Language glossary.
Facilitation Tips
- Before the meeting: Prepare 5+ colors of sticky notes + large whiteboard/Miro template; must ensure domain experts participate; clarify the workshop scope; introduce the color conventions and process 5 minutes in advance
- During the meeting: Step 1 no discussion allowed (the most common cause of failure); prioritize business language; mark Hot Spots with purple sticky notes and do not resolve them on the spot; strictly manage timeboxes; pay attention to maintaining energy
- After the meeting: Take photos immediately for archiving; digitize the outputs into domain documents within 24h; schedule a Hot Spot follow-up meeting; use the outputs as input for
ddd-domain-designerinput
Online Tool Recommendations
Miro (distributed teams, recommended) | Mural (video conferencing integration) | draw.io (free and lightweight) | Physical Whiteboard (preferred for co-located teams)
Relationship with ddd-domain-designer
Recommended path: event-storming (workshop outputs) → domain-designer (detailed aggregate design + code implementation) → Architecture Skill (architecture implementation)
event-storming focuses on facilitating collaborative workshops (domain experts + the whole team), producing a sticky note wall, event list, and BC division (conceptual level); domain-designer focuses on developer aggregate design (developers + architects), producing code structure, aggregate classes, and repository interfaces (code level).
Customization
| Scenario | Suggested Adjustment |
|---|---|
| Small team (3-5 people) | Merge Step 1+2 into 20min+15min; Skip Step 6 and discuss directly |
| Large team (10+ people) | Extend Step 1 to 45min with parallel sticky note posting in groups; add 10min group report-back to Step 6 |
| Time-constrained (1 hour) | Do only Step 1-3 (event divergence + ordering), and schedule the subsequent steps separately |
| Complex domain (multiple BCs) | Hold a separate workshop for each BC; do not try to cover them all at once |
| Cross-language team | Use bilingual sticky notes (Chinese events + English terms), with the Chinese consensus as authoritative |
Quick Start
Send the requirements directly to the AI; the following opening lines can be used as-is:
"帮我组织一个电商订单履约的事件风暴工作坊，需要 6 步流程"
"我要做一个保险投保领域的事件风暴，领域专家有 2 位"
"做一次用户中台的事件风暴，重点关注认证和权限"
"之前做完了物流配送的事件风暴，帮我整理产出物"
If you're not sure where to start, just say "help me do event storming," and the AI will automatically guide you through it.
Security & Safety
This skill is pure documentation. It contains no executable scripts, collects no user data, accesses no external services or networks.
Gotchas — Common Pitfalls
- Skip Brainstorming and discuss directly: You must first diverge freely and then prioritize. Discussing event correctness too early will kill creativity.
- Technical people leading: It must be led by domain experts, with developers taking notes and asking questions. A model led by developers is not the real business.
- CRUD-style commands: Do not write "CRUD Order"; commands should be business actions:
PlaceOrder、CancelOrder。 - Forgetting Hot Spots: All disagreements and uncertain boundaries must be recorded as purple sticky notes. Hot Spots that are not recorded will be forgotten afterward.
- Skip Aggregate Discovery: Finish after Step 4. Without the clustering in Step 5, event storming is just a pretty sticky-note wall.
- Missing domain experts: This is a fatal mistake. Event storming without domain expert participation will produce an incorrect domain model.
- Trying to cover the entire enterprise at once: Too large a scope leads to superficial work. It is recommended to start with the core subdomain, one BC at a time.
- Outputs not organized → the sticky-note wall becomes decoration: Within 24h after the workshop ends, the outputs must be digitized, otherwise memory will be lost. Use the
workshop-output-template.mdtemplate to organize quickly. - No ubiquitous language record: The consensus on definitions of terms that naturally arises during the storm must be recorded to become a Ubiquitous Language table. Not recording it means no consensus was reached.
FAQ
| Question | Answer |
|---|---|
| How long does the workshop take? | One BC takes about 2.5 hours for the complete 6 steps. The total cycle for a medium-sized project is about 2 weeks. |
| What if there is no formal domain expert? | Choose from business staff/product managers/senior developers with domain experience. |
| Which is better, online or offline? | Offline (physical whiteboard) has the strongest sense of interaction; online (Miro) allows asynchronous collaboration. |
| How many participants are needed? | Minimum 3 people (domain expert + developer + product), optimal 6-8 people. |
| How are the outputs used? | As ddd-domain-designer input, entering aggregate detailed design and code implementation. |
| How large a scope can one workshop cover? | One BC at a time is recommended. Complex domains can be split into multiple workshops by subdomain. |
| Must the facilitator be a DDD expert? | It is not necessary to be proficient in DDD, but you need to understand the 6-step process and color conventions, and have facilitation skills. |
| How do the outputs correspond to code? | Aggregate candidates → domain-designer Aggregate, events → Domain Event classes, BC → microservice modules. |
References
For details, see references/ and examples/：
- Templates: sticky-note-template.md, timeline-example.md, workshop-output-template.md
- Guides: facilitation-checklist.md, workshop-deep-guide.md, context-mapping.md, partme-12-event-storming-modeling.md, ddd-strategic.md, clean-ddd-hexagonal-strategic.md
- Examples: 5 workshop cases (e-commerce order fulfillment, insurance underwriting, user middle platform, logistics delivery, financial payments)