Event Storm

Use this when you need to understand a business process, break down a monolith, identify domain boundaries, or create alignment between business and engineering teams. This skill helps prepare, facilitate, and capture the outputs of an Event Storming workshop.

Full guide: See the Architecture Discovery Workshop Playbook for the complete method.

Process

Step 1: Gather inputs

Ask the user:

1. Business domain or process — what system or workflow are we storming? (e.g., "order fulfillment," "patient intake," "loan origination")
2. Scope — are we mapping the full process or a specific slice?
3. Participants — who will attend? (domain experts, engineers, stakeholders, analysts)
4. Current state — is there an existing system diagram, architecture doc, or process map?
5. Session format — in-person (stickies on a wall) or virtual (Miro/FigJam)?
6. Output destination — conversation only, Miro board, FigJam, Notion, or file?

If the user gives partial input, proceed with what's available and list assumptions.

Step 2: Prepare the session

Generate a facilitation kit:

1. Sticky note legend — define the color coding:

   • Orange: Domain Events (past tense, e.g., "Order Placed")
   • Blue: Commands (actions that trigger events, e.g., "Place Order")
   • Yellow: Actors (who triggers the command)
   • Pink: External Systems (systems involved)
   • Red: Hot Spots / Pain Points (problems, questions, risks)
   • Green: Read Models / Views (information needed to make decisions)
   • Purple: Policies / Business Rules (rules that react to events)

2. Session agenda (1-2 hours):

   • 10 min — intro, ground rules, legend
   • 30 min — chaotic exploration (everyone adds events)
   • 15 min — enforce timeline (order events left to right)
   • 15 min — add commands, actors, external systems
   • 15 min — mark hot spots and pain points
   • 15 min — identify thin slices and bounded contexts

3. Ground rules — no laptops, write one idea per sticky, past tense for events, no solutions yet.

Step 3: Capture domain events

Guide the user through event discovery. For each event:

• Name it in past tense (e.g., "Payment Received," not "Receive Payment")
• Identify the triggering command and actor
• Note external systems involved
• Flag pain points with red stickies

Organize events into a left-to-right timeline.

Domain starter sets

If the domain matches one of these patterns, offer the starter set to get past the blank-canvas problem. Participants refine, reorder, and add missing events from here.

Clinical Trial Startup (CRO/sponsor trial activation):

#	Event	Command	Actor	External System
1	Protocol Received	Receive Protocol	Study Manager	Sponsor portal
2	Feasibility Survey Sent	Send Feasibility Survey	Site Navigator	CTMS
3	Feasibility Response Received	Submit Feasibility Response	Site (PI/Coordinator)	Email / portal
4	Site Identified	Identify Candidate Site	Study Manager	CTMS
5	Site Selected	Select Site	Study Manager / Sponsor	CTMS
6	CDA Executed	Execute CDA	Legal / Regulatory	DocuSign / email
7	Regulatory Package Prepared	Prepare Regulatory Package	Site Navigator	eTMF
8	Regulatory Package Submitted	Submit to IRB/EC	Site Navigator / Regulatory Coordinator	IRB portal
9	IRB Approval Received	Approve Protocol	IRB/Ethics Committee	IRB portal
10	Contract Sent	Send Site Contract	Budget Analyst / Legal	Email / contract system
11	Budget Negotiated	Negotiate Budget	Budget Analyst / Site	Email / phone
12	Contract Executed	Execute Contract	Legal	DocuSign
13	Site Documents Collected	Collect Site Documents	Site Navigator	eTMF / email / fax
14	Document Deficiency Identified	Flag Missing Document	Site Navigator	eTMF
15	SIV Scheduled	Schedule Site Initiation Visit	CRA	CTMS / email
16	SIV Completed	Complete SIV	CRA / PI	CTMS
17	Site Activated	Activate Site	Study Manager	CTMS
18	First Patient Screened	Screen Patient	PI / Study Coordinator	EDC
19	First Patient Enrolled	Enroll Patient	PI / Study Coordinator	EDC / CTMS

Common hot spots for this domain: Contract/budget negotiation delays (40% of startup time), document chase loops (documents arrive via email/fax/portal with no single tracking), protocol amendment cascading rework, IRB re-submission cycles, missing institutional knowledge after staff turnover.

Step 4: Identify thin slices and bounded contexts

From the event timeline:

1. Thin slices — identify 2-4 connected event paths that accomplish a business objective. Start with the happy path.
2. Bounded contexts — group related events that share a ubiquitous language and could be owned by one team.
3. Communication patterns — mark which interactions are synchronous (request/response) vs. asynchronous (publish/subscribe).

Step 5: Generate the Event Storming output

Use the event storming template to produce the deliverable:

---

Event Storming: (Domain/Process Name)

Date: (date) Participants: (list) Scope: (what was mapped)

Domain Events (timeline order)

#	Event	Command	Actor	External System	Notes
1	(Event name — past tense)	(Command)	(Actor)	(System)	(Notes)

Bounded Contexts

Context	Key Events	Ubiquitous Language	Owner/Team
(Context name)	(Events in this context)	(Key terms)	(Team)

Thin Slices

Slice	Path (events)	Business Objective	Type
(Name)	Event A → Event B → Event C	(Objective)	Happy path / Alternate / Exception

Hot Spots

Issue	Location	Impact	Notes
(Pain point)	(Which context/event)	High/Med/Low	(Details)

Communication Patterns

From	To	Type	Description
(Context A)	(Context B)	Sync/Async	(What's communicated)

---

Step 6: Share and distribute (optional)

If the user requested a tool destination in Step 1:

• Miro — use doc_create to post the event storming output, or table_create for the events table
• FigJam — use generate_diagram to create a flowchart of the event timeline
• Notion — use notion-create-pages with the output as content
• File — save to ./output/event-storming/(domain-name)-events.md

Step 7: Generate bounded context output and architecture decisions

After the event storm capture, produce architecture-ready output:

Bounded context detail:

For each identified bounded context, document:

### Bounded Context: {{Context Name}}

**Core domain events:** {{list of events in this context}}
**Aggregate roots:** {{the key entities that own state in this context}}
**Ubiquitous language:** {{terms specific to this context -- same word may mean different things in different contexts}}
**Context relationships:**

| Related context | Relationship type | Integration pattern |
|----------------|-------------------|-------------------|
| {{context}} | Upstream / Downstream / Conformist / Anti-corruption layer / Shared kernel | Sync API / Async event / Shared DB / File transfer |

**Ownership recommendation:** {{which team should own this context and why}}

Architecture Decision Records:

For each significant domain modeling decision, generate an ADR using /adr-generate:

Common decisions to record:

• Why certain events were grouped into a bounded context (vs. split)
• Where the context boundaries fall and the trade-offs considered
• Which communication patterns (sync vs. async) were chosen and why
• Where anti-corruption layers are needed between contexts

Related skills: Use /adr-generate to produce formal ADRs from these decisions.

Step 8: Review

Ask the user:

• Are any events missing from the timeline?
• Do the bounded contexts feel right, or should we split/merge any?
• Do the aggregate roots capture the right state ownership?
• Are the context relationships and integration patterns realistic?
• Which thin slice should we validate first?
• Are there hot spots that block us from proceeding to Boris modeling?

Uncertainty Policy

Topic	Tolerance	Action
Business process being modeled	Low	STOP and ask — wrong process means wrong events
Event sequencing and causality	Low	STOP and ask — incorrect event order breaks the model
Domain terminology	Medium	Assume + flag [ASSUMED] — capture in ubiquitous language, team resolves
Bounded context groupings	Medium	Assume + flag [ASSUMED] — hypotheses refined in Boris
Hot spot severity	Medium	Assume + flag [ASSUMED] — team triages during review
Actor/persona assignments	High	Best guess — team validates during walkthrough

Default: STOP and ask when a topic is not listed above.

Related skills

• /boris-model — next stage: translate events into service relationships
• /snap-document — final stage: document APIs, data, and risks per bounded context
• /architecture-discovery — skill set that chains all three stages
• /facilitation-guide — generate a facilitation script for the session

Output locations

Format	Location	Notes
Markdown	Conversation or saved file	Always produced. Source of truth.
Miro doc	User's specified Miro board	Via Miro MCP.
FigJam diagram	FigJam	Event timeline as flowchart.
Notion page	User's specified Notion location	Via Notion MCP.
File	./output/event-storming/(domain)-events.md	Local file.