Model types

EventStorming

EventStorming is a workshop format for exploring a business domain quickly, with everyone in the room. It is usually the first model a team makes: you lay out what happens in the business, in order, and the boundaries reveal themselves.

An EventStorming canvas with a timeline of domain events, commands, and policies.
An EventStorming canvas with a timeline of domain events, commands, and policies.

The elements

Element Color What it is
Domain Event Orange Something that happened that the business cares about. Written in the past tense: Order Placed.
Command Blue An action someone or something takes that causes an event.
Policy Purple A rule that reacts to an event: whenever this happens, do that.
Saga / Process Purple A longer-running process coordinating several steps.
Hotspot Red-pink Conflict, confusion, or an unanswered question. Put them up early and often.
Entity Yellow Something with an identity that changes over time.
Domain Service Yellow Domain behavior that does not belong to a single entity.
Value Object Yellow A value with no identity of its own.
View Green Information someone reads to make a decision.
User Role Yellow The kind of person doing the work.
External System Pink A system outside your boundary.
Opportunity Light green Something worth pursuing.
Problem Red Something in the way.
User Interface White A screen or interaction surface.
Query White A question asked of the system.
Note White Anything else worth writing down.
Subdomain Green A container that groups elements into a candidate boundary.

The toolbar groups the smaller ones: Control holds Policy and Saga, Model holds Entity, Domain Service, and Value Object, and Extra holds User Interface, Query, and Note.

The EventStorming toolbar with the Model dropdown open.
The EventStorming toolbar with the Model dropdown open.

How a session usually goes

  1. Events first. Fill the canvas with domain events, past tense, roughly left to right in time. Do not worry about order or duplicates yet.
  2. Sort into a timeline. Drag them into sequence. Disagreements about order are the useful part.
  3. Add the causes. In front of each event, put the command that triggered it and the user role or external system behind that command.
  4. Add the reactions. Where an event causes something else, add the policy between them.
  5. Mark the hotspots. Every "it depends", every argument, every unknown gets a hotspot.
  6. Find the boundaries. Group related elements and see the shape of the subdomains.

Grouping into subdomains

Select the elements that belong together and press the Subdomain button (or D). They are wrapped in a named container. The button is only enabled when the selection can legally be grouped. Elements that are already inside a subdomain, and subdomains themselves, cannot be re-grouped.

Subdomains are what a Context Map is generated from, so this step is what carries the workshop forward.

Keyboard

Key Element
E Domain Event
C Command
P Policy
G Saga / Process
H Hotspot
N Entity
V View
U User Role
S External System
O Opportunity
? Problem
I User Interface
T Note
D Group selection in a Subdomain

Generating a Context Map

Once the subdomains are drawn, create a Context Map from this model and each subdomain arrives as a bounded context, bringing its elements with it. Choose auto sync while the EventStorming model is still moving, and switch to manual once the Context Map is being shaped by hand. See Linked models.