Event Storming Vocabulary

Event Storming is the most widely used technique for discovering the domain model of an event-driven system.

Why Event Storming is powerful:
• Brings domain experts (who understand the business) and developers (who build the system) into the same room
• Uses physical sticky notes on a long wall — the timeline is forced to be spatial and visible
• Surfaces hidden complexity, edge cases, and business rules that formal requirements documents miss

The sticky note colour convention:

Colour	Concept	Example
🟠 Orange	Domain event	OrderPlaced
🔵 Blue	Command	PlaceOrder
🟡 Yellow	Aggregate	Order
🟣 Purple/Pink	Policy	When OrderPlaced → ReserveInventory
🟢 Green	View / Read model	CustomerOrderHistory

Key vocabulary:
• Big Picture Event Storming — high-level discovery of the entire business domain
• Design-Level Event Storming — detailed modelling of a specific bounded context
• Chaotic exploration — first phase where participants add events freely without order

Domain events are the core building block of Event Storming and event-driven design.

Three essential characteristics of a domain event:

① Past tense — it has already happened; it is a fact, not an intention
✓ OrderShipped, PaymentDeclined, AccountSuspended
✗ ShipOrder (that's a command), Shipment (that's an entity)

② Business meaningful — domain experts (not just developers) care about this fact
✓ CustomerUpgradedToPremium
✗ DatabaseRowUpdated (technical, not a domain concept)

③ Immutable — once it happened, it cannot be changed (only new events can supersede it)

Domain event naming convention:
• Format: NounPastParticiple → InvoiceGenerated, SubscriptionCancelled
• Use the ubiquitous language of the domain — words that domain experts use in conversation

Key vocabulary:
• Domain event — a business-meaningful fact that has occurred
• Ubiquitous language — shared vocabulary between domain experts and developers
• Past tense naming — signals that the event is a completed fact, not a request

Commands express intent; events record what happened — they are cause and effect.

The command → aggregate → event flow:
PlaceOrder (command) → Order aggregate validates business rules → OrderPlaced (event)

What can send a command:
• A user action via the UI
• Another service (via API call or message)
• A policy reacting to a previous event ("When PaymentReceived → ShipOrder")

Commands vs events — key differences:

	Command	Domain event
Tense	Present (an intent)	Past (a fact)
Can be rejected?	Yes — business rules may block it	No — it already happened
Naming	PlaceOrder, CancelSubscription	OrderPlaced, SubscriptionCancelled

Key vocabulary:
• Command — an intent / request to change state (may be rejected)
• Command handler — the code that receives and processes a command
• Aggregate — the domain object that enforces business rules when processing a command

Policies are the "when X, do Y" rules that drive automated behaviour in event-driven systems.

Policy structure:
When [Domain Event] → Issue [Command]

Examples of policies:
• "When OrderPlaced → Issue ReserveInventory command"
• "When PaymentFailed → Issue CancelOrder command"
• "When UserInactiveLongerThan90Days → Issue SendReEngagementEmail command"

Why policies matter in event storming:
• They reveal hidden business rules that domain experts know but rarely document
• They define the automation boundaries — which reactions can be automated vs need human decision
• In implementation, policies become event consumers that subscribe to events and publish commands

Key vocabulary:
• Policy — an automated business reaction (when X → do Y)
• Pivotal event — a domain event that many policies react to (a critical business moment)
• Automation boundary — the distinction between automated reactions and human decisions
• Choreography — when services react to events via policies (no central orchestrator)

Hotspots are the most valuable output of an Event Storming session — they reveal where the real work is.

What triggers a hotspot:
• Domain experts disagree about how a process works
• Nobody in the room knows the rule that governs a specific event
• Two different "schools of thought" exist about a business process
• A business rule is known but not documented anywhere
• The team has found a gap in the system's current implementation

How hotspots are used after the session:
① Prioritised as a list of discovery tasks — questions to research before design begins
② Scheduled as follow-up workshops with the right domain experts in the room
③ Used to identify high-risk areas in the system design (places most likely to have bugs)

Key vocabulary:
• Hotspot — an area of uncertainty, disagreement, or missing knowledge (red sticky note)
• Discovery task — a question or research item created from a hotspot
• Bounded context — a boundary within which a specific domain model applies consistently
• Context map — a diagram showing how bounded contexts relate to each other