Skip to content
←Domain-Driven Design

// Domain-Driven Design · 10

Event Storming

Experts + developersleads toEvents on a wallleads toAggregates and contexts

Map the business as sticky-note events on a timeline, with experts.

How it fits together

Event Storming structure«client»Claims handleractor, yellowClaim summaryread model, greenApprove Payoutcommand, blue«external»Payment providerexternal system, pinkClaimaggregate, yellowpayout ≤ coverMake Paymentcommand, bluePayout Approveddomain event, orangePay approved claimspolicy, lilacwhenever approved, pay1 reads2 issues3 handled4 emits5 triggers6 issues7 sent to
uses / callscreatespublishes / notifies· numbered steps replay in order
  • Claims handler uses / calls Claim summary (1 reads)
  • Claims handler uses / calls Approve Payout (2 issues)
  • Approve Payout uses / calls Claim (3 handled)
  • Claim creates Payout Approved (4 emits)
  • Payout Approved publishes / notifies Pay approved claims (5 triggers)
  • Pay approved claims creates Make Payment (6 issues)
  • Make Payment uses / calls Payment provider (7 sent to)

Spot it

  • Devs and experts describe the flow differently
  • Nobody can explain the process end to end
  • Unsure where service boundaries should go

It costs

Needs the right people for hours and a good facilitator; the wall is raw input, not a design.

Go deeperThe full explanation and what to ask for · 1 min readExpand

A workshop format created by Alberto Brandolini. Domain experts and developers put domain events (orange, past tense: Claim Submitted, Payout Approved) on a long timeline, then argue about order and gaps. Pink hotspots mark disagreements, questions and pain points. The conversation is the point; the wall shows where knowledge is missing.

At design level you add the grammar: an actor (small yellow) issues a command (blue) to an aggregate (large yellow), which produces an event; a policy (lilac, "whenever X, then Y") reacts to an event by issuing the next command; read models (green) show what the actor needed to decide; external systems (pink) sit at the edges.

Clusters of commands and events around the same rules suggest aggregates, and places where the language or ownership changes suggest bounded context boundaries. When NOT to: a small CRUD feature with an obvious flow does not need a half-day workshop.

Ask for it

  • domain event (orange)
  • command (blue)
  • policy (lilac)
  • read model (green)
  • hotspot (pink)
  • big picture vs design level

Run a 3-hour Event Storming on claims handling with 2 claims handlers, 1 underwriter, 3 devs and a facilitator: big picture first (orange events left to right, pink hotspots), then add commands, actors, policies and read models for the payout flow, and propose aggregates and context boundaries.

Connects to