EventStorming Workshop Summary Template

Record an EventStorming session: events timeline, commands, actors, policies, read models, hotspots, context candidates

Architektur & SystemdesignStandardEventStorming (Alberto Brandolini)event storming summaryAktualisiert 20.10.2026

Anleitung: Use it within 48 hours of a big picture, process or design level EventStorming workshop. Fill the domain events timeline and hotspots first, then link the board photos. The main pitfall is smoothing over disagreements, which are the session's most valuable output.

Vorschau

EventStorming Workshop Summary: [Domain or process name]

Record of an EventStorming workshop: the format, who took part, the domain events in time order, the commands, actors, policies, read models and external systems around them, the aggregates and hotspots found, the bounded context candidates and the agreed next steps. Based on the concepts of EventStorming as created by Alberto Brandolini. Replace every [bracketed] value and every row marked Example. Worked examples come from a big picture session on insurance claims.

Field	Value
Workshop title	[Claims handling: big picture]
Format	[Big picture / Process modelling / Software design]
Date and duration	YYYY-MM-DD, [6 hours]
Location / tool	[Room 4.12 / Miro board link]
Facilitator	[@facilitator]
Scribe	[@scribe]
Board photos / export	[Link]
Summary version	[0.1]
Last updated	YYYY-MM-DD

1. Goal and format

Goal: [Example: Build a shared understanding of the claims process from first notice of loss to payment, find the main bottlenecks and propose candidate bounded contexts for the new claims platform.]

Format	Used?	Scope covered
Big picture	Example: Yes	First notice of loss to payment and recovery
Process modelling	Example: No	Planned for the assessment process
Software design	Example: No	Planned after context boundaries are agreed

Out of scope: [Example: Policy sales and renewals; fraud analytics.]

2. Participants

Name	Role	Perspective brought
Example: @claims-lead	Claims handling manager	Day-to-day process and exceptions
Example: @adjuster	Senior loss adjuster	Assessment of property damage
Example: @finance	Claims finance analyst	Payments, reserves, recovery
Example: @dev-lead	Engineering lead	Current systems and constraints
[Name]	[Role]	[Perspective]

Missing perspectives: [Example: No one from the call centre; their view of first notice of loss was represented second-hand.]

3. Notation legend

Element	Colour on board	Meaning
Domain event	Orange	Something that happened that domain experts care about, in past tense
Command	Blue	A decision or request that causes an event
Actor	Small yellow	A person or role who issues a command
Policy	Lilac	A reaction rule: "whenever X happens, then do Y"
Read model	Green	Information an actor needs to make a decision
External system	Pink (wide)	A system outside the scope that sends or receives events
Aggregate	Large yellow	A cluster of behaviour and data that enforces consistency
Hotspot	Red / magenta	A problem, question, disagreement or risk

4. Domain events timeline

ID	Phase	Domain event	Pivotal?	Triggered by	Notes
EV-01	Example: Notification	Loss Reported	Yes	Policyholder call or web form	Up to 30% arrive by email outside office hours
EV-02	Example: Notification	Policy Coverage Checked	No	Claims handler	Manual lookup in two systems
EV-03	Example: Notification	Claim Registered	Yes	Claims handler	Claim number issued
EV-04	Example: Assessment	Adjuster Assigned	No	Allocation policy	Based on region and claim size
EV-05	Example: Assessment	Damage Assessed	Yes	Adjuster	Site visit for claims above 5,000
EV-06	Example: Settlement	Settlement Offered	No	Claims handler
EV-07	Example: Settlement	Settlement Accepted	Yes	Policyholder
EV-08	Example: Payment	Payment Issued	Yes	Finance	Two-day lag from batch job
[EV-NN]	[Phase]	[Event in past tense]	[Yes / No]	[Actor, policy or system]	[Notes]

5. Commands and actors

Command	Actor	Read model used	Resulting event(s)
Example: Report Loss	Policyholder	Policy summary	Loss Reported
Example: Register Claim	Claims handler	Coverage check result	Claim Registered
Example: Record Assessment	Adjuster	Claim file, photos, repair estimates	Damage Assessed
Example: Offer Settlement	Claims handler	Assessment, policy limits, reserve	Settlement Offered
[Command]	[Actor]	[Read model]	[Event]

6. Policies

ID	Policy	Applied by today	Notes
POL-01	Example: Whenever a claim is registered above 5,000, then assign a field adjuster	Team leader, by hand	Should be automatic
POL-02	Example: Whenever settlement is accepted, then request payment	Claims handler, by email to finance	Source of the two-day lag
POL-03	Example: Whenever no assessment exists after 10 days, then escalate	Nobody	Missing policy; claims stall
[POL-NN]	[Policy]	[Person / System / Nobody]	[Notes]

7. Read models and external systems

Type	Name	Used for	Owner	Issue
Read model	Example: Coverage summary	Deciding whether a loss is covered	Policy admin	Built by hand from two screens
Read model	Example: Claim file	Assessment and settlement	Claims	Photos stored in email
External system	Example: Policy admin system	Policy and cover data	IT policy team	Batch export only
External system	Example: Bank payment gateway	Paying settlements	Finance	Daily batch
[Type]	[Name]	[Use]	[Owner]	[Issue]

8. Aggregates

Aggregate	Commands handled	Invariants protected	Events emitted
Example: Claim	Register Claim, Close Claim	One open claim per loss event and policy	Claim Registered, Claim Closed
Example: Settlement	Offer Settlement, Accept Settlement	Total offered never exceeds policy limit minus excess	Settlement Offered, Settlement Accepted
[Aggregate]	[Commands]	[Invariants]	[Events]

9. Hotspots

ID	Hotspot	Type	Votes	Owner	Next step
HS-01	Example: Coverage check takes 20 minutes per claim	Bottleneck	9	@claims-lead	Prototype coverage read model
HS-02	Example: Finance and claims disagree on when a claim is "closed"	Language conflict	7	@domain-architect	Define term in both contexts
HS-03	Example: No owner for recovery from third parties	Missing responsibility	5	@head-of-claims	Decide ownership
[HS-NN]	[Hotspot]	[Bottleneck / Question / Conflict / Risk / Missing]	[N]	[@owner]	[Step]

10. Bounded context candidates

Candidate	Events covered	Language signal	Confidence	Next validation
Example: Claim Notification	EV-01 to EV-03	"Loss", "first notice"	High	Bounded context canvas
Example: Assessment	EV-04, EV-05	"Inspection", "estimate"	Medium	Process modelling session
Example: Settlement and Payment	EV-06 to EV-08	"Reserve", "settlement", "payment"	Low (may be two contexts)	Process modelling with finance
[Candidate]	[Events]	[Signal]	[High / Medium / Low]	[Step]

11. Flow overview

The flow below summarises the main path across the three candidate contexts, with the policy that currently causes the payment delay.

12. Decisions and next steps

Decisions taken: [Example: Treat Claim Notification as the first context to rebuild; keep Assessment in the legacy system for now.]

ID	Action	Owner	Due	Status
ACT-01	Example: Run process modelling session on settlement with finance	@facilitator	YYYY-MM-DD	Open
ACT-02	Example: Draft bounded context canvas for Claim Notification	@dev-lead	YYYY-MM-DD	Open
ACT-03	Example: Propose definition of "claim closed"	@domain-architect	YYYY-MM-DD	Open
[ACT-NN]	[Action]	[@owner]	YYYY-MM-DD	[Open / Done]

Standard and licence note

Based on the EventStorming method created by Alberto Brandolini (https://www.eventstorming.com), using its concepts of formats (big picture, process modelling, software design), domain events, commands, actors, policies, read models, external systems, aggregates and hotspots. EventStorming is a method, not a licensed document; no text from its books or materials is reproduced, and all wording and examples here are original to this collection. Template licence: MIT.