Notation and Building Blocks

Core Concepts

Event Storming works because every element on the board carries a precise, shared meaning. The sticky note colors are not decorative — they are the language. When everyone in the room understands that an orange note always refers to something that already happened, and a blue note always refers to an intent to act, the board can be read by any participant without narration.

Orange — Domain Events

"Order Placed." "Account Created." "Payment Failed." These are things that have already happened. They cannot be undone.

Domain events are the backbone of the model. They are written in past tense — always — and placed on a shared timeline running left to right in chronological order. Orange sticky notes should be the most abundant element on the board; every other element exists in relation to them.

A well-formed domain event is named after a business fact, not a technical operation. "Record Updated" is a technical operation. "Inventory Level Fell Below Threshold" is a business fact. If you cannot explain why an event matters to a domain expert, it probably does not belong on an orange note.

---

Blue — Commands

Commands are the requests or intentions that cause domain events to occur. Written in the present tense, a command is placed directly before the orange event it triggers: "Place Order" → "Order Placed."

Commands can come from users, from other systems, or from automated policies. The key distinction is directionality: a command is an attempt; a domain event is the confirmed outcome. Not every command succeeds — modeling this explicitly reveals failure paths that naive flow diagrams miss.

---

Yellow (large) — Aggregates

Aggregates appear as larger yellow sticky notes placed between a command and the event it produces. An aggregate receives commands through its public interface and emits domain events as a result. On the board, it clusters together the commands and events that must remain consistent with each other.

Visually, the layout reads: Command (blue) → Aggregate (large yellow) → Domain Event (orange). This trio is the fundamental unit of design-level Event Storming and maps directly onto the DDD tactical pattern: aggregates are the consistency boundaries of the domain model.

---

Lilac / Purple — Policies

Policies capture reactive business logic. Their pattern is always "whenever event X occurs, then command Y." A policy sits after the event that triggers it and before the command it produces.

Policies make automation visible. When you see a lilac note on the board, you are looking at a business rule that runs without human decision-making. This makes policies especially important surfaces for architectural discussion: they often reveal implicit coupling, background jobs, or saga-like flows that nobody had written down anywhere.

---

Green — Read Models

Read models are the information views that actors need in order to make a decision or issue a command. A green note answers the question: "What does the user need to see before they can act?"

Green notes are typically placed below the command they inform. They reveal the query side of the model — what data must be available, in what shape, and for whom. In systems following CQRS patterns, read models become first-class architectural artifacts surfaced here in the discovery phase.

---

Pink — External Systems

External systems are actors outside the domain boundary that the team does not own or control. Pink notes mark these integration points as black boxes: they can trigger commands and receive events, but the team makes no design decisions about their internals.

The distinction between pink (external) and large yellow (aggregate) is architecturally significant. An aggregate is something the team designs; an external system is something the team integrates with. Confusing the two leads to over-scoped designs or to hidden dependencies being treated as owned components.

---

Red — Hotspot Markers

Hotspot markers use red (or pink) rotating sticky notes and have a specific, non-semantic role: they mark where the model is uncertain, contested, confusing, or incomplete. A hotspot is not a problem — it is a finding. It tells the team: "We do not yet have shared understanding here."

Hotspots become the team's design and research backlog. Rather than derailing the session to resolve a disagreement, the facilitator marks it, keeps the session moving, and returns later with the right people or additional information.

When participants actively disagree, the same mechanism applies: mark the contested area with a red or purple note rather than forcing consensus in the moment. Some domain disagreements require reflection, stakeholder negotiation, or information that is not present in the room. Surfacing the disagreement explicitly is more valuable than manufacturing false consensus.

---

The Notation as a Whole

The power of Event Storming notation is not in any individual color — it is in the relationships between them. The canonical flow at design level reads:

Fig 1

The notation is deliberately minimal — three colors are enough to run a productive session at the big-picture level. Additional note types (green for read models, lilac for policies, pink for external systems) are introduced progressively as the session moves from event exploration toward design-level modeling.

---

Worked Example

Consider an e-commerce checkout flow. Here is how the notation maps to a real sequence:

Scenario: A customer checks their cart, decides to place an order, and a confirmation email is sent automatically.

Step	Element	Color	Note text
1	Read Model	Green	"Cart Summary with item list and total"
2	Command	Blue	"Place Order"
3	Aggregate	Large Yellow	"Order"
4	Domain Event	Orange	"Order Placed"
5	Policy	Lilac	"Whenever Order Placed → Send Confirmation Email"
6	Command	Blue	"Send Confirmation Email"
7	External System	Pink	"Email Service Provider"
8	Domain Event	Orange	"Confirmation Email Sent"

Reading this sequence left to right, any participant in the room can follow the chain of cause and effect without any technical background. The green note tells us what the user sees before they act. The blue note captures their intention. The large yellow note shows what business entity enforces the rules of placing an order. The orange note records the confirmed outcome. The lilac note shows the automated reaction. The pink note marks the third-party service the team does not own.

Where hotspots would appear: If the team disagrees on whether "Order Placed" should be a single event or split into "Order Reserved" and "Payment Captured," that is a hotspot — mark it red and continue. If nobody knows what happens when the email service is unavailable, mark that too.

---

Common Misconceptions

"Commands and events are interchangeable." They are not. A command is an intent that may fail; a domain event is a confirmed fact that has already occurred and cannot be reversed. Confusing these leads to models where the distinction between "we tried to do X" and "X happened" is lost — which is precisely the distinction that matters most in event-driven architectures.

"Yellow sticky notes always mean the same thing." Actors (user personas or roles) are sometimes represented with small yellow notes. Aggregates use large yellow notes. When both conventions are in use, consistency matters — if the room uses large yellow for aggregates and small yellow for actors, everyone must apply this distinction the same way or the model becomes ambiguous.

"Hotspots mean the session went badly." Hotspots are findings, not failures. A board with many hotspots after a first pass means the session surfaced genuine complexity that was previously invisible. A board with no hotspots is more likely to reflect groupthink or insufficient diversity of perspectives than a genuinely well-understood domain.

"External systems (pink) can be redesigned by the team." Pink notes mark what the team does not own. Placing a system on a pink note is a deliberate architectural statement: its behavior is a constraint, not a design decision. Treating an external dependency as an aggregate (yellow) obscures ownership boundaries that have real operational and organizational consequences.

"Policies always represent automation." Policies capture the whenever...then... reaction pattern, which can be automated or human-initiated. A policy like "Whenever a Refund is Requested → a Customer Service Agent Reviews the Request" is a human process, but it still belongs on a lilac note because it describes a defined, reactive business rule.

---

Quiz

1. A sticky note reads: "Submit Payment." What color should it be, and what type of element is it?

• a) Orange — domain event
• b) Blue — command
• c) Lilac — policy
• d) Green — read model

2. During an Event Storming session, two domain experts strongly disagree about whether a specific step belongs to one business process or another. What is the correct facilitation move?

• a) Hold a vote and use the majority answer
• b) Remove the contested element from the board
• c) Mark the area with a hotspot and continue the session
• d) Ask the technical lead to decide

3. A team places "Payment Gateway" on the board. It is a third-party service they integrate with but do not control. What color note should they use?

• a) Large yellow — aggregate
• b) Blue — command
• c) Pink — external system
• d) Green — read model

4. What is the defining characteristic of a well-formed domain event?

• a) It is written in the imperative mood
• b) It is written in the past tense and represents a confirmed business fact
• c) It is placed after the aggregate that handles it
• d) It always has a corresponding policy

5. A lilac sticky note reads: "Whenever Order Placed → Notify Warehouse." What does this represent?

• a) A command issued by a user
• b) An aggregate handling a business transaction
• c) A reactive business policy triggered by a domain event
• d) A read model that an actor consults before acting

Answers: 1-b, 2-c, 3-c, 4-b, 5-c