Skip to main content

EventStorming at Capstone Scale

What This Concept Is​

EventStorming is a workshop technique (originated by Alberto Brandolini) for discovering the flow of events through a domain. You brain-storm domain events on sticky notes, lay them out in time order along a wall, and let the model emerge from the timeline. Domain Message Flow is its close cousin: you track the messages (commands, events, queries) that cross context boundaries.

At capstone scale -- one person, one domain, one week -- the technique collapses down to a disciplined solo ritual:

  • Write every domain event you can imagine, in past tense ("invitation sent", "note added", "ticket scanned", "row imported").
  • Lay them out on a single timeline from left to right.
  • For each event, mark the command that triggered it and the actor who issued the command.
  • Highlight hot spots -- events where the behavior is unclear, disputed, or depends on details you don't yet know.
  • Draw loose bounded contexts around clusters of events that share language.
  • Promote every hot spot to either a risk-register row (concept 02) or an ADR (concept 12).

You can do this solo on a whiteboard, in Miro, or in a plain markdown file. The physical medium does not matter. The output does.

EventStorming has three canonical flavors -- Big-Picture, Process-Level, and Software-Design -- but for a 6-week capstone you only need the first two. Big-Picture surfaces the whole domain; Process-Level zooms into the MVP's happy path.

Why It Matters Here (In the Capstone)​

Most solo capstone designs are built around entities and screens. That is fine for CRUD apps and disastrous for anything with behavior. EventStorming forces you to think in events, which is how your domain actually behaves in time. The events you discover become the scaffolding of the Ubiquitous Language (concept 06), the seams of bounded contexts (concept 05), and the steps of the MVP happy path (concept 03).

Second: EventStorming surfaces risks. Every "hot spot" on your timeline is a question you do not have an answer to. Every one of them belongs on the risk register. If you EventStorm and no hot spots show up, you are not being honest -- you have stormed a system you already knew, or you have been too abstract.

Third: EventStorming makes your core subdomain visible. The cluster with the most events, the most hot spots, and the most commands is almost always the core. That cluster is where your week-2-4 effort lives.

Concrete Example(s) -- from a real capstone​

Example A -- inventory service Big-Picture pass (abbreviated):

[Staff] --receiveScan--> "Scan event recorded"
                            "On-hand incremented" [HOT: what if offline?]
[Staff] --pickScan--> "Pick event recorded"
                            "On-hand decremented" [HOT: can pick go negative?]
[Staff] --offlineQueueSync--> "Queued scans flushed"
                            "Duplicate scans rejected" [HOT: by what key?]
[Admin] --runReconciliation--> "Daily rollup computed"
                            "Reconciliation report written"
[System] --nightlyCompaction--> "Scan log compacted"

Reading the timeline: three clusters emerge -- a "scan" cluster (receive + pick + offline sync), a "reconciliation" cluster (rollup + reports), and a "system maintenance" cluster (compaction). The "scan" cluster is the core. Three hot spots go straight onto the risk register, one of which ("by what idempotency key?") becomes ADR material.

Example B -- ticketing platform Process-Level pass (MVP happy path only):

[Organizer] --publishEvent--> "Event published"
                                "Seat tiers initialized" [pre: caps sum to total]
[Buyer] --reserveSeat--> "Seat reservation attempted"
                                "Seat decremented" [HOT: concurrent decrements?]
                                "Reservation confirmed" OR "Reservation failed (sold out)"
[Buyer] --confirmPurchase--> "Ticket issued"
                                "QR generated"
[DoorStaff] --scanQR--> "Ticket validated" OR "Ticket already used" [HOT: offline scan?]
                                "Entry recorded"

The single hottest spot ("concurrent decrements") is a consistency invariant -- no oversell -- that will drive ADR-002 (store choice) more than any performance requirement.

Example C -- finance aggregator Big-Picture pass:

[User] --uploadCsv--> "CSV staged"
                         "Rows hashed for idempotency" [HOT: hash scheme?]
[System] --runImport--> "New rows persisted"
                         "Duplicate rows skipped"
                         "Rules engine evaluated each row"
                         "Rows categorized" OR "Rows marked uncategorized" [HOT: rule precedence?]
[User] --requestCashflowReport--> "Report generated"
                                    "Report written to disk"

The "rules engine evaluated each row" event is the core subdomain. The hot spot on rule precedence becomes an ADR (how are rules ordered? YAML source? first-match? priority number?).

In every case: past-tense events, imperative commands, named actors, explicit hot spots, and clusters that suggest bounded contexts. The mechanics are the same; only the domain nouns change.

Common Confusion / Misconceptions​

  • "It's just brainstorming." EventStorming is brainstorming with constraints: events must be past tense, commands must be imperative, actors must be named, and the timeline must be linear. Drop the constraints and it becomes a mind map.
  • "I'm solo, so I don't need it." The constraints matter more when you are solo, because you have no collaborator to catch you skipping. Solo EventStorming is how you interrogate your own model. It takes 45 minutes and catches the week-3 surprise now.
  • Future-tense event smell. Writing "user will add note" is a user story, not an event. Events are facts about the past. If you cannot write it in past tense, it is a wish.
  • Entity drift. Writing nouns on stickies ("Retro", "Note") instead of events ("Retro created", "Note added"). Entities are the output of EventStorming, not the input. If your wall has entities, rewrite.

How To Use It (In Your Capstone)​

Solo Big-Picture pass (45-60 min):

  1. Open a large whiteboard or markdown document. Set a timer.
  2. Brain-dump 20-40 past-tense events from your capstone domain.
  3. Arrange in time order, left to right.
  4. Add actors and commands above each event.
  5. Mark every point where you hesitated, disagreed with yourself, or noticed a behavior you don't know how to implement. Those are hot spots.
  6. Draw loose boundaries around clusters of events that share language.
  7. Count: events per cluster, hot spots per cluster. The biggest, hottest cluster is the core.

Solo Process-Level pass (30-45 min):

  1. Pick the one most important happy path (typically the MVP path, concept 03).
  2. Zoom in on its events only.
  3. For each event, specify the precondition (what must be true) and postcondition (what changes).
  4. Every hot spot on this path becomes an architecture driver or a risk register row.

Promotion discipline (10 min):

  1. Every hot spot -> either a risk row (concept 02) or an ADR stub (concept 12). No floating hot spots.
  2. Every cluster -> a candidate bounded context (concept 05).
  3. Every recurring noun -> a glossary candidate (concept 06).

See also (integrative)​

EventStorming is the capstone's concentrated version of the DDD discovery material from S7 M03 and the event-oriented modeling from S8 M03.

External references (curation-validated this session):

Check Yourself​

  1. What is a hot spot, and where does it end up in your capstone documents?
  2. Why does EventStorming use past-tense events instead of future-tense "user stories"?
  3. Name one cluster of events in your capstone that suggests a bounded context. What language do its events share?
  4. Which cluster has the most hot spots? Is it also the cluster you are most excited about? If not, check whether you've misidentified the core.
  5. How many of your hot spots are already on the risk register? If fewer than half, you are storing anxiety in the wrong place.

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (45 min). Run a solo Big-Picture pass on your capstone. Target: 20+ events, 3-5 hot spots, 2-3 cluster boundaries. Commit to library/raw/domain/eventstorm.md.
  • Drill 2 (10 min). Promote every hot spot: is it a risk-register row, an ADR stub, or a glossary entry? No hot spot stays unclaimed.
  • Drill 3 (30 min). Run a Process-Level pass on the MVP happy path only. For each event, write precondition and postcondition in one line each.
  • Drill 4 (20 min, weekly). In week 3, re-open the storm. What events changed? Which hot spots closed? Which new ones appeared? The storm is alive; update it.
  • Drill 5 (15 min, once). Show the storm to a peer (or imagine a grader). Can they follow the timeline and point at the core? If not, your clusters are weak.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.