Skip to main content

EventStorming Clinic

Retrieval Prompts​

  1. State from memory the three levels of EventStorming and what each produces.
  2. List the sticky-note color legend -- at least six colors -- with the meaning of each.
  3. State the rule for event name tense and give one good and one bad example.
  4. Name the order in which sticky notes are added to the board (events -> commands -> actors -> policies -> read models -> aggregates).
  5. State two reasons the facilitator should not also be the senior architect.

Compare and Distinguish​

Separate these pairs cleanly:

  • command vs event -- who writes each, and what tense do they use?
  • policy vs read model -- both sit "around" the timeline but do different jobs. What jobs?
  • big-picture vs process-level -- what is the audience of each, and what is the output?
  • process-level vs design-level -- which introduces aggregates, and why only at that level?
  • EventStorming vs sequence diagram -- what does EventStorming capture that a sequence diagram cannot?

Common Mistake Check​

Identify the error in each:

  1. A sticky note reads Row inserted into shipments table.
  2. The team skips the 10 minutes of silent chaos writing because "we already know the process."
  3. A policy sticky note reads Shipping service calls the billing API.
  4. Every event is followed by exactly one command in the same color.
  5. The facilitator is also the tech lead for the team and keeps intervening to clarify.
  6. Three engineers and no domain experts are in the room.
  7. After the session the board is photographed and never used again.
  8. Design-level EventStorming skips red hot-spots because "we want progress."

Mini Application -- Parcel Returns "Initiate a Return" Process​

You are running a process-level EventStorming on "customer initiates a return for a delivered parcel and either gets a refund or a store credit." Target output: a usable process board, red hot-spots, and candidate aggregates.

Produce:

  1. Timeline. At least 12 past-tense domain events in order, left-to-right. Use real operational vocabulary (e.g., ReturnInitiated, ReverseLabelGenerated, ReturnPickupScheduled, ParcelReceivedAtReturnsHub, InspectionCompleted, RefundIssued, StoreCreditIssued, ReturnRejected).
  2. Commands. Place at least 5 commands, each linked to the event they produce and to an actor.
  3. Actors. Name at least 3 (customer, returns clerk, finance, carrier-gateway).
  4. External systems. At least 2 pink stickies (carrier gateway, fraud detection).
  5. Policies. At least 4 lilac policies. Include at least one with a conditional ("whenever X AND condition, do Y").
  6. Read models. At least 2 green stickies (e.g., Returns Queue, Customer Return History).
  7. Hot-spots. At least 3 red hot-spots -- real tensions you would expect to find in practice (e.g., "who owns rejection criteria?").
  8. Candidate aggregates. Draw yellow stickies for 2-3 aggregates and list their commands and events.
  9. Candidate bounded contexts. Cluster the timeline into contexts with vertical lines. Propose names.
  10. 1-page debrief. One paragraph each: three biggest findings, three biggest risks, three next actions.

You may represent the board in ASCII, Mermaid, or a photograph-style layout. Imitation of real-life sticky-note placement is fine.

Evidence Check​

This page is complete only if, given a new domain, you can:

  • run a 90-minute process-level EventStorming solo or with 2-3 peers
  • produce a board that passes these tests:
    • every event is past-tense
    • every policy has an explicit trigger
    • at least 2 red hot-spots are present (if there are zero, the session was not honest)
    • at least 2 candidate bounded contexts emerge with reasoning
  • converge to at least 2 candidate aggregates with their commands and invariants
  • write a same-day 1-page summary that your product manager can read without the board in front of them