# 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.

<!--
Guidance: How to use this template
- Fill it in within 48 hours of the workshop, while memory is fresh. Take
  photos of the wall and link them; this document is the searchable
  version, not a replacement for the photos.
- Keep the sticky-note colour legend (section 3) the same across sessions
  so summaries can be compared.
- Record disagreements and hotspots honestly. They are the most valuable
  output of a big picture session.
- Big picture sessions usually fill sections 4, 9 and 10 only lightly in
  the command and aggregate parts; design level sessions fill all sections.
-->

| 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

<!-- Guidance: State the question the workshop had to answer and why this format was chosen. Big picture explores a whole business flow with many stakeholders; process modelling details one process with its rules; software design level designs aggregates and boundaries for implementation. -->

**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

<!-- Guidance: The right mix matters more than the notation. Record who was there and, just as important, which perspective was missing. -->

| 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

<!-- Guidance: The colours used on the wall. The standard conventions are shown; adjust if your board used others. -->

| 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

<!-- Guidance: The events in time order, grouped by phase or pivotal event. Write events in past tense in domain language. Mark pivotal events (big state changes that split the timeline into phases). -->

| 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

<!-- Guidance: For each important event, which command caused it and who issued it. Commands use imperative verbs. An event with no command usually comes from a policy or external system. -->

| 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

<!-- Guidance: Reaction rules that connect an event to the next command. Write them as "whenever ... then ...". Note whether a person or the system applies them today. Hidden policies applied by experienced staff are a frequent finding. -->

| 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

<!-- Guidance: Information needed for decisions, and systems outside the scope. External systems often hide integration pain and data ownership questions. -->

| 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

<!-- Guidance: Mainly for process and design level sessions. Name the aggregate after the business concept, list the commands it handles, the invariants it protects and the events it emits. -->

| 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

<!-- Guidance: Every red sticky from the wall. Classify and prioritise them; dot-voting at the end of the session is a quick way to rank them. -->

| 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

<!-- Guidance: Boundaries suggested by changes in language, actors, pivotal events and swimlanes. These are candidates for further work, not decisions. -->

| 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

<!-- Guidance: A small diagram of the main flow and candidate boundaries. It is a summary of the wall, not a copy. -->

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

```mermaid
flowchart LR
  subgraph N["Claim Notification"]
    A["Loss Reported"] --> B["Claim Registered"]
  end
  subgraph AS["Assessment"]
    C["Adjuster Assigned"] --> D["Damage Assessed"]
  end
  subgraph S["Settlement and Payment"]
    E["Settlement Offered"] --> F["Settlement Accepted"]
    F -->|"POL-02 (manual)"| G["Payment Issued"]
  end
  B -->|"POL-01"| C
  D --> E
```

## 12. Decisions and next steps

<!-- Guidance: What was agreed in the room and what happens next. Every action has an owner and a date. -->

**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.