Design system / rev A

Event Storming Board

A modelling surface for change-management requests. The chrome is monochrome steel on paper; all color in the product belongs to the sticky grammar, so the timeline reads as a legend at a glance. Conventions follow eventstorming.com, adapted where the digital medium can do better than a paper wall.

base
Industry
ground
#f2f2f3
steel
#5980a6
grid
8px / lane 208

Domain message flow — the messaging view

One scenario, ordered messages between contexts, actors and systems.

§13 answers who integrates with whom. This answers in what order, one scenario at a time, and it is where a chatty boundary becomes visible. Participants are the collapsed clouds of §09 — off the grid, so the cloud is the context — plus the thin-stroke gear and person glyphs already used in the systems lane.

§13 answers who integrates with whom. This answers in what order, one scenario at a time, and it is where a chatty boundary becomes visible. A scenario is a slice of the timeline: pick a start and an end event, and the flow is generated from the stickies whose trigger arrow crosses a region edge.

Scenario: Vendor bank details changed, no exceptions raised

CR-2291 · 7 MESSAGES · 4 CONTEXTS · 1 SYSTEM · 1 ACTOR · AS-IS

  1. 1. Assess vendor risk
    COMMAND · C-005 MK
  2. 2. Request security review
    COMMAND · C-007 MK
  3. 3. Reserve budget
    COMMAND · C-009 MK
  4. 4. Finance re-checks the budget
    EVENT · E-023 MK
  5. 5. Approve change 2
    COMMAND · C-011 MK
  6. 6. Schedule change window
    COMMAND · C-013 MK
  7. 7. Create vendor record
    COMMAND · C-015 MK
message-flow/fixtures/message-flow-model.ts — §25’S SCENARIO OVER §10’S BOARDCLICK A MESSAGE: EVERY ONE LINKS BACK TO ITS STICKY AND ITS CANVAS ROW
Fidelity: §25’s figure prints 6 MESSAGES · 4 CONTEXTS · 2 SYSTEMS. This board yields seven messages, four contexts, one system and one actor for the same slice, because the counts are computed rather than written down. The figure’s own first two hops are not crossings on §10’s board — ServiceNow reaches its command on a publishesTo connector where §25 counts trigger arrows, and the requesting manager is an actorId, not a connector — and both sit ahead of step 01, outside the slice. SAP MDG has no connector at all and SAP · budget is reached by a publish, so neither is a participant. The board contributes one crossing the figure does not draw: the assumed "Finance re-checks the budget" branch, drawn dashed at 72%.
Notation
  • cloud · 2.6px core
  • cloud · 1.8px supporting
  • cloud · 1.8px generic
  • gear · a system
  • person · an actor or persona
All five marks are drawn here from `message-flow/participant.fixtures.ts` — the same array `Participant.test.ts` renders — so the three cloud weights sit beside the two glyphs at one size. The gear and the person are no longer specification-only: `CN-27` puts Archer GRC on the flow above and `CN-28` puts the risk analyst there, two arrows `message-flow/fixtures/message-flow-model.ts` adds to §10’s board rather than to `domain/fixtures/vendor-onboarding.ts`, which the board counts, the BPMN slice, the CML tray and the context map all read from.
  • Cloud a bounded context, flat bottom, §09 weights: 2.6px core, 1.8px supporting or generic, 1.2px dashed outside our boundary.
  • Gear — a system. Person — an actor or persona. Both thin-stroke, no fill, as in the systems lane.
  • Dashed arrow direction of the message, sender to receiver. Numbered, so the order is explicit without lanes.
  • Sticky colour the sticky grammar of §02, unchanged. A message is a sticky already on the board, not a new object.
Generated, not drawn
  • Messages are the stickies whose trigger arrow crosses a region edge, in timeline order. Rename a sticky and the flow renames with it.
  • A scenario is stored as a start event, an end event and a layout, so several scenarios read from one board without duplicating stickies.
  • Every message links back to its sticky, its canvas row — inbound or outbound communication — and its relationship on the map.
What it is for
  • Count the crossings. Six messages across four contexts for one field change is the argument for moving a boundary, and this is the artefact that shows it.
  • Compare as-is against to-be on the same scenario; the flow with fewer hops is the one to propose.
  • A message with no receiving context, or a receiver with no matching inbound row on its canvas, goes to the review queue.