Event Storming
Concept of the skill
Use when discovering a domain through events, commands, actors, policies, aggregates, read models, external systems, and temporal workflows before implementation.
Coverage
Discover domain behavior through temporal events and decisions. Covers domain events, commands, actors, policies, aggregates, read models, external systems, hotspots, timelines, invariants, and handoff into bounded-context, state-machine, data, and API design.
Philosophy of the skill
Event storming starts from "what happened" because events expose real business flow faster than nouns do. Noun-first modeling often freezes premature assumptions. Event-first modeling reveals time, causality, policy, and exceptions.
Do not confuse domain events with technical notifications. "OrderPlaced" is business meaning. "WebhookReceived" is transport detail.
Method
- List domain events in past tense.
- Place them on a timeline.
- Add commands that cause events.
- Add actors and external systems that issue commands or receive outcomes.
- Add policies: "when event X happens, if condition Y, then command Z."
- Identify aggregates that enforce invariants.
- Mark hotspots, missing decisions, temporal ambiguity, and unclear ownership.
- Hand off to bounded-context, state-machine, data, or API design only after the flow is coherent.
Verification
Do NOT Use When
| Use instead |
When |
webhook-integration |
You are implementing provider webhooks, signatures, retries, and deduplication. |
event-contract-design |
You already selected the event and need schema, envelope, topic, compatibility, replay, or fixtures. |
state-machine-modeling |
You already know the lifecycle and need formal states, transitions, and guards. |
entity-relationship-modeling |
You need tables, keys, indexes, constraints, or data lifecycle. |
api-design |
You need endpoint, request, response, and status-code design. |
Skill Graph context
Classification
- Subject:
software-architecture
- Public:
true
- Domain:
architecture/domain-discovery
- Scope: Use when discovering a domain through events, commands, actors, policies, aggregates, read models, external systems, and temporal workflows before implementation. Do NOT use for event schema/topic contracts (use
event-contract-design), webhook handler implementation (use webhook-integration), generic state transition modeling (use state-machine-modeling), or persistence schema design (use entity-relationship-modeling).
When to use
- map the order lifecycle as domain events before we design tables or APIs
- which commands, policies, and external systems are hidden in this workflow?
- use event storming to find aggregate boundaries for fulfillment
- turn this incident-prone business process into events and decisions
Not for
- implement Shopify webhook signature verification and idempotent retries
- draw the state machine for this one status field
- create a normalized data model and indexes
- write event-bus infrastructure code
- define the schema, topic, compatibility, and fixtures for a selected event
Related skills
- Verify with:
conceptual-modeling, system-interface-contracts
- Related:
system-interface-contracts, webhook-integration, api-design, state-machine-modeling, event-contract-design, conceptual-modeling
Keywords
event storming, domain events, commands, aggregates, policies, read models, temporal workflow, event-driven discovery, process modeling
1---2name: event-storming3description: Use when discovering a domain through events, commands, actors, policies, aggregates, read models, external systems, and temporal workflows before implementation. Do NOT use for event schema/topic contracts (use `event-contract-design`), webhook handler implementation (use `webhook-integration`), generic state transition modeling (use `state-machine-modeling`), or persistence schema design (use `entity-relationship-modeling`). Do NOT use for implement Shopify webhook signature verification and idempotent retries. Do NOT use for draw the state machine for this one status field. Do NOT use for create a normalized data model and indexes. Do NOT use for write event-bus infrastructure code. Do NOT use for define the schema, topic, compatibility, and fixtures for a selected event.4license: MIT5---6# Event Storming78## Concept of the skill910Use when discovering a domain through events, commands, actors, policies, aggregates, read models, external systems, and temporal workflows before implementation.1112## Coverage1314Discover domain behavior through temporal events and decisions. Covers domain events, commands, actors, policies, aggregates, read models, external systems, hotspots, timelines, invariants, and handoff into bounded-context, state-machine, data, and API design.1516## Philosophy of the skill17Event storming starts from "what happened" because events expose real business flow faster than nouns do. Noun-first modeling often freezes premature assumptions. Event-first modeling reveals time, causality, policy, and exceptions.1819Do not confuse domain events with technical notifications. "OrderPlaced" is business meaning. "WebhookReceived" is transport detail.2021## Method22231. List domain events in past tense.242. Place them on a timeline.253. Add commands that cause events.264. Add actors and external systems that issue commands or receive outcomes.275. Add policies: "when event X happens, if condition Y, then command Z."286. Identify aggregates that enforce invariants.297. Mark hotspots, missing decisions, temporal ambiguity, and unclear ownership.308. Hand off to bounded-context, state-machine, data, or API design only after the flow is coherent.3132## Verification3334- [ ] Events are named in past tense and carry business meaning35- [ ] Commands are imperative and have actors or policies36- [ ] Policies are explicit condition-action rules37- [ ] Aggregates are tied to invariants, not guessed from nouns38- [ ] External systems and transport details are separated from domain events39- [ ] Hotspots and unanswered questions are recorded40- [ ] The timeline can replay a real scenario end to end4142## Do NOT Use When4344| Use instead | When |45|---|---|46| `webhook-integration` | You are implementing provider webhooks, signatures, retries, and deduplication. |47| `event-contract-design` | You already selected the event and need schema, envelope, topic, compatibility, replay, or fixtures. |48| `state-machine-modeling` | You already know the lifecycle and need formal states, transitions, and guards. |49| `entity-relationship-modeling` | You need tables, keys, indexes, constraints, or data lifecycle. |50| `api-design` | You need endpoint, request, response, and status-code design. |5152## Skill Graph context5354<!-- skill-graph-context:start (generated — do not edit by hand) -->5556**Classification**57- Subject: `software-architecture`58- Public: `true`59- Domain: `architecture/domain-discovery`60- Scope: Use when discovering a domain through events, commands, actors, policies, aggregates, read models, external systems, and temporal workflows before implementation. Do NOT use for event schema/topic contracts (use `event-contract-design`), webhook handler implementation (use `webhook-integration`), generic state transition modeling (use `state-machine-modeling`), or persistence schema design (use `entity-relationship-modeling`).6162**When to use**63- map the order lifecycle as domain events before we design tables or APIs64- which commands, policies, and external systems are hidden in this workflow?65- use event storming to find aggregate boundaries for fulfillment66- turn this incident-prone business process into events and decisions6768**Not for**69- implement Shopify webhook signature verification and idempotent retries70- draw the state machine for this one status field71- create a normalized data model and indexes72- write event-bus infrastructure code73- define the schema, topic, compatibility, and fixtures for a selected event7475**Related skills**76- Verify with: `conceptual-modeling`, `system-interface-contracts`77- Related: `system-interface-contracts`, `webhook-integration`, `api-design`, `state-machine-modeling`, `event-contract-design`, `conceptual-modeling`7879**Keywords**80- `event storming`, `domain events`, `commands`, `aggregates`, `policies`, `read models`, `temporal workflow`, `event-driven discovery`, `process modeling`8182<!-- skill-graph-context:end -->
jacob-balslev