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.

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.

How a session usually goes
- Events first. Fill the canvas with domain events, past tense, roughly left to right in time. Do not worry about order or duplicates yet.
- Sort into a timeline. Drag them into sequence. Disagreements about order are the useful part.
- Add the causes. In front of each event, put the command that triggered it and the user role or external system behind that command.
- Add the reactions. Where an event causes something else, add the policy between them.
- Mark the hotspots. Every "it depends", every argument, every unknown gets a hotspot.
- 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.