Besides orange sticky notes for domain events, an Event Storming board typically uses several other colors for commands, actors, policies, read models, and external systems. What does each of these represent, and how do they connect to form a coherent flow?
answer
- orange=event, blue=command, yellow=actor
- lilac/purple=policy (whenever...then)
- green=read model, pink=external system
- aggregate box groups commands+events under one consistency boundary
- notation added in layers, not all at once
basics
~20 sBesides orange notes for events, Event Storming boards use other colors for who did something (actors), what they tried to do (commands), automatic rules that react to events (policies), information someone needs to decide (read models), and outside systems involved (external systems).
solid answer
~50 sThe full Event Storming notation extends the orange domain-event note with several complementary elements, each on its own color, so the board reads like a sentence: a small yellow 'actor' note names who initiates an action; a blue 'command' note captures the intent they express ('Place Order'); that command, when successfully handled, produces the orange 'event' to its right ('Order Placed'). A lilac/purple 'policy' note captures an automated reactive rule - 'whenever X happens, do Y' - which typically bridges one event to the next command without a human actor involved. A green 'read model' note represents the information view a user needs before issuing a command. A pink note marks an external system the process depends on but the team doesn't control. Later, as the model matures, boxes are drawn around clusters of commands and events to show the aggregate consistency boundary that enforces the business rules for that slice of the process.
go deeper
Should recognize and name the basic elements (event, command, actor) and give a one-line description of each.
Should explain how commands, actors, policies, and read models connect to each other to form a readable flow, not just define each in isolation.
Should know which notation to introduce and when during a live session (events first, richer grammar in a second pass) and recognize policies as a common source of hidden or incorrect business logic.
Should be able to design a facilitation sequence that scales the notation's complexity to the group's experience level, and connect each notation element forward to its downstream design artifact (actors to authorization model, read models to query design, aggregates to transactional boundaries).
## Why the notation grows Event Storming's notation is deliberately minimal at the start — just orange domain events — and grows richer as the group needs more precision to explain how the process actually flows. Understanding the full grammar matters because each element answers a different modeling question, and skipping straight to a subset produces a board that looks complete but can't actually be read like a coherent story. ## Events, commands and actors - **Domain event (orange)** — the base element: a business-significant fact, phrased in past tense, that other parts of the system or other people can react to — `Order Placed`, `Payment Authorized`, `Shipment Delayed`. - **Command (blue)** — once a rough timeline of events exists, the group asks "what caused each event?" The answer is usually a command: an intent expressed by someone, phrased as an imperative — `Place Order`, `Authorize Payment`. A command is a request, not a guarantee; it can be rejected (validation failure, business rule violation), in which case no event follows. - **Actor (small yellow note, sometimes a stick figure or persona icon)** — above or beside the command sits the role or person issuing the command — `Customer`, `Warehouse Clerk`, `Fraud System`. Actors matter because they clarify authorization boundaries later ("can a Customer really issue this command, or only Support?"). ## Policies, read models, external systems and aggregate boundaries Not every event is caused directly by a human command. - **Policy (lilac/purple, often labeled "whenever...then...")** — captures an automated reactive rule that listens for an event and, without human intervention, issues the next command: "Whenever Payment Declined, then Cancel Reservation." Policies are where a lot of hidden business logic lives, and they're a common source of production bugs when the policy's trigger condition is more nuanced than the sticky note implies (e.g., "except during the fraud-review grace period"). - **Read model (green)** — represents a view of data a user needs before they can meaningfully issue a command, the order-summary screen a customer sees before clicking `Place Order`, and it exists to remind the group that commands don't happen in an informational vacuum. - **External system (pink)** — marks a boundary where the process depends on something the team doesn't own, a payment gateway or a shipping carrier's API, which is a strong hint that resilience and integration-failure discussion is needed there. - **Aggregate boundaries** — finally, once the group has enough of the flow laid out, they draw aggregate boundaries around a cluster of commands and events that share a single consistency boundary: the smallest unit that must be transactionally consistent to enforce a given business rule. ## What the richer grammar buys The reason this richer grammar exists, rather than just listing events, is that a bare event timeline answers "what happens" but not "why" or "who's responsible." - Once you add **commands and actors**, the board starts answering "who can trigger what," which is exactly the information needed later for authorization design and UI/API surface design. - Adding **policies** exposes automated business logic that's otherwise invisible until a bug report reveals it. - Adding **read models** forces the group to notice that a command that looks trivial ("Approve Discount") actually depends on information ("current spend this quarter") that nobody has said where it comes from yet. ## The trade-off The trade-off is **board complexity versus expressive power**. | Board | What it gives you | What it costs | |---|---|---| | A pure-event timeline | fast to build and easy for newcomers to scan | it can't capture the causal "why" | | A fully-notated board with all element types | much more informative | takes longer to build and requires the group to already understand the notation, which adds friction for a first-timer group | Most facilitators therefore introduce events first, get the rough timeline agreed, and only then layer in commands/actors/policies/read models in a second pass — introducing every color on slide one tends to overwhelm a first-time group. ## A production failure, and a worked example A common production-relevant failure is treating a policy note as fully specifying the business rule when it's actually a simplification; teams that skip validating the policy note against the real domain expert ("does whenever payment fails really mean immediately, or after N retries?") end up encoding the wrong rule once this policy gets implemented in code. A concrete worked example: in an order-fulfillment flow, `Order Placed` (event) triggers a policy "Whenever Order Placed, then Reserve Inventory" (policy -> command), which the Warehouse system executes, producing `Inventory Reserved` or `Inventory Reservation Failed` (events) — and it's exactly at that fork that read models and further policies, such as a backorder policy, get discovered.
- What's the difference between a command being rejected and an event never happening?A command is just a request; if validation or a business rule fails, the command handler simply doesn't produce an event - there's no separate 'rejection event' unless the team explicitly models one (e.g., 'Order Rejected'). Whether to model rejections as their own events is a design decision made once the group starts thinking about what downstream policies need to react to failures.
- How do read models relate to CQRS?The read model note on an Event Storming board is the conceptual ancestor of a CQRS read model: a purpose-built view optimized for a specific decision or screen, separate from the write-side aggregate. Event Storming surfaces the need for it during discovery; CQRS is one way, not the only way, to implement it in code.
- Why put an actor note above a command instead of just naming the actor in the command text?Keeping them as separate notes lets the group spot patterns fast - e.g., noticing that five different commands are all issued by 'Fraud System' clusters authorization/automation concerns visually, which is much harder to see if the actor is buried inline in text on every command note.
Like color-coding a movie script: orange lines are what happened on screen, blue lines are a character's spoken intent, yellow tags say who's speaking, purple stage directions are automatic reactions ('whenever the lights dim, the music starts'), and the aggregate box is like grouping a scene's dialogue under one set that must stay internally consistent.
saying these in an interview costs you the question
- only ever mentions orange events and can't name any other element
- calls a policy note 'just another event'
- doesn't know that a command can fail without producing an event
- treats the read model note as unnecessary/decorative
- introduces all colors to a first-time group in the first five minutes and wonders why the group is confused