⌘ The Architecture Reference

Ddd application · Domain-Driven Design · Intermediate

EventStorming

A low-tech collaborative workshop that models a business process as a timeline of domain events — building shared knowledge and a ubiquitous language fast.

Ddd application Intermediate ⏱ 4 min read Complete

🧭 Analogy

Imagine the whole team standing at a long wall, building a comic strip of how the business actually works — panel by panel, in sticky notes. Disagreements about what happens next surface instantly, and by the end everyone shares the same story. That’s EventStorming.

A low-tech modeling workshop

EventStorming (created by Alberto Brandolini) is a collaborative workshop where a diverse group brainstorms and rapidly models a business process as a series of domain events on a timeline, progressively enriching it with commands, actors, policies, read models, external systems, aggregates, and bounded contexts. Its primary value is the knowledge sharing and ubiquitous-language formation during the session — the model is a bonus. The process is guidance, not hard rules.

Invite anyone related to the domain (engineers, domain experts, product owners, testers, UI/UX, support) — more diversity means more knowledge. Keep groups to ~10 in person (5 online), take the chairs out so people participate, and never let supplies be a bottleneck. A typical session runs 2–4 hours.

The ten steps

graph TD
S1["1. Unstructured exploration<br/>domain events (orange, past tense)"] --> S2["2. Timelines<br/>order events, happy path first"]
S2 --> S3["3. Pain points (pink diamond)"]
S3 --> S4["4. Pivotal events (vertical bar)"]
S4 --> S5["5. Commands (blue) + actors (yellow)"]
S5 --> S6["6. Automation policies (purple)"]
S6 --> S7["7. Read models (green)"]
S7 --> S8["8. External systems (pink)"]
S8 --> S9["9. Aggregates (large yellow)"]
S9 --> S10["10. Bounded contexts (group aggregates)"]
  1. Unstructured exploration — Brainstorm domain events (orange, past tense); no ordering yet.
  2. Timelines — Order events; start with the happy path, then alternatives; fix duplicates and gaps.
  3. Pain points — Mark bottlenecks, manual steps, and missing knowledge (rotated pink diamonds) throughout.
  4. Pivotal events — Mark context/phase changes with a vertical bar; these hint at bounded-context boundaries.
  5. Commands — Add imperative commands (light blue) before events; attach actors (small yellow) where obvious.
  6. Policies — Add automation policies (purple) connecting an event to an auto-triggered command, with decision criteria (“only for VIP customers”).
  7. Read models — Add green notes for the view an actor uses to decide.
  8. External systems — Add pink external-system notes (input or output).
  9. Aggregates — Organize related commands and events into aggregates (large yellow), commands on the left, events on the right.
  10. Bounded contexts — Group related aggregates into candidate boundaries.

Every command needs a trigger

By the end, every command should be triggered by an actor, an automation policy, or an external system. If a command has no trigger, you’ve found a gap in the model — exactly the kind of “white spot” the workshop exists to surface.

Pink does double duty

The color scheme is conventional, and pink means both pain points (diamond) and external systems — build a visible legend with real sticky notes as you introduce each element so nobody gets confused. Orange = events (past tense), light blue = commands (imperative), small yellow = actors, large yellow = aggregates, purple = policies, green = read models, vertical bar = pivotal events.

When to run one

Best learned by doing

Use EventStorming to build a ubiquitous language, model a process, explore new requirements, recover lost domain knowledge from a legacy system, improve a process, or onboard people. Don’t use it when the process is simple or obvious. Watch the group’s energy, draw in quiet participants, and run a “big-picture-first” pass (steps 1–4 across a wide domain) before dedicated per-process sessions. The resulting model can even be a blueprint for an event-sourced domain model.

The elements connect in a consistent “grammar” — reading it left to right is how you sanity-check the model:

graph LR
Actor["Actor (yellow)"] --> Cmd["Command (blue)"]
Policy["Policy (purple)"] -.-> Cmd
Ext["External system (pink)"] -.-> Cmd
Cmd --> Agg["Aggregate (large yellow)"]
Agg --> Ev["Event (orange, past tense)"]
Ev --> RM["Read model (green)"]
Ev -.->|"triggers"| Policy

The advice for the whole DDD journey distills to one line: “Always watch your ubiquitous language, and when in doubt, do EventStorming.”

See also

When to use it — and when not

✅ Reach for it when

  • To build a ubiquitous language and align mental models across a diverse group.
  • To model a complex business process or explore new requirements collaboratively.
  • To recover lost domain knowledge from a legacy system, or to onboard people.

⛔ Think twice when

  • When the business process is simple or obvious — the workshop's overhead isn't worth it.
  • Don't expect a polished model on the first pass; the value is the conversation.
ddd-strategicUbiquitous Language

Cultivate one shared, consistent language for the business domain — DDD's cornerstone practice and its single biggest predictor of success.

ddd-strategicBounded Contexts

Divide the ubiquitous language into smaller, internally consistent models — each its own model, physical, and ownership boundary.

ddd-applicationDesign Heuristics and Evolving Design

Answer DDD's perennial 'it depends' with a decision tree driven by subdomain type — then evolve those decisions as the business changes.

Check your understanding

Score: 0 / 4

1. What is EventStorming's primary benefit?

The model and the ubiquitous-language head start are bonuses; the primary value is the knowledge sharing and alignment that happens during the session.

2. How are domain events written on the sticky notes?

Domain events are something interesting that already happened, written in past tense on orange notes; commands are imperative on light-blue notes placed before the events.

3. What does a 'pivotal event' indicate?

Pivotal events mark a significant context/phase change (e.g., 'order shipped') with a vertical bar and hint at where bounded contexts might be drawn.

4. By the end of a session, every command should be triggered by...?

Steps 5-8 ensure every command traces to an actor (yellow), an automation policy (purple), or an external system (pink).

Comments

Sign in with GitHub to join the discussion.