[Anchor Proposal]: Event Storming according to Alberto Brandolini

[SidekickJohn]

Proposed Term

Event Storming according to Alberto Brandolini

Context (Optional)

Helpful in planning or executing or learning about Event Storming Workshops. Also an interesting approach for an AI agent to review a software product (i.e. analyze Domain Events, Aggregates etc. from this Legacy Software and structure the output like you would in an Event Storming Workshop according to Alberto Brandolini).

Pre-submission Checklist

• I have searched existing anchors and this term is not already included
• This term refers to a well-established concept (not something I invented)

[JensGrote]

Proposal: Event Storming according to Alberto Brandolini as a new semantic anchor

(German version below)

---

Open questions

1. Granularity: Big Picture vs. Design Level vs. Process Modeling. Brandolini differentiates three Event Storming variants with different goals and participant profiles. Should the anchor cover all three (umbrella), or only Big Picture as a standalone anchor with Design Level/Process Modeling as sub-anchors? Given that all three share the same notation (colored stickies), I'd recommend a single anchor covering all variants, with "Big Picture" and "Design Level" as Core Concepts.

2. Differentiation from Domain-Driven Design. Event Storming is a method, DDD is a framework. The method presupposes DDD vocabulary (Aggregates, Bounded Contexts, Domain Events). Should Event Storming reference domain-driven-design as a prerequisite or as a related anchor?

3. AI Agent Use Case: Reverse Event Storming. The proposer suggests using an AI agent to analyze legacy code through an Event Storming lens. This is an actionable prompt pattern (identify state transitions → map to Domain Events → cluster into Aggregates → discover Bounded Contexts). Should this be an explicit "When to Use" scenario, or is it better left to a separate skill?

---

Source verification

Origin: Alberto Brandolini, first presented at the Italian DDD community meetup in 2012, blog post 2013.

Key publication: Alberto Brandolini, "Introducing EventStorming" (Leanpub, self-published, continuously updated since 2013, ISBN 9781006258961)

Canonical blog post: http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html

Community adoption: Widely practiced in DDD communities, major conference circuit (DDD Europe, KanDDDinsky, Explore DDD). Multiple derivative works by Vaughn Vernon, Nick Tune, Kenny Baas-Schwegler.

---

Assessment against quality criteria

Criterion	Verdict	Evidence
Precise	✅	Specific workshop format with a defined notation: orange=Domain Event, blue=Command, yellow=Aggregate, lilac=Policy, green=Read Model, pink=External System, red/rotating=Hot Spot. Three distinct levels (Big Picture, Design Level, Process Modeling) with different goals.
Rich	✅	Activates: DDD tactical patterns, collaborative domain discovery, bounded context identification, aggregate boundary design, policy/saga discovery, integration point mapping, timeline-based reasoning, chaotic exploration → structured model.
Consistent	✅	High LLM recognition. Consistently triggers the sticky-note taxonomy and workshop flow. Well-documented in Brandolini's book and dozens of conference talks.
Attributable	✅	Single clear originator: Alberto Brandolini (2012/2013). No attribution ambiguity.

---

Gap analysis

What the catalog has	What Event Storming adds
domain-driven-design → strategic + tactical DDD patterns	A specific method to discover those patterns collaboratively — the "how do we get to bounded contexts" problem
event-driven-architecture → architecture style (async messaging)	The modeling technique that precedes EDA design — discovering which events exist before deciding how to route them
user-story-mapping → linear feature prioritization along backbone	Non-linear domain exploration starting from events, not user activities
cqrs → Command/Query segregation pattern	Event Storming discovers Commands and Queries before deciding on CQRS architecture
(nothing)	Collaborative domain modeling as a first-class anchor — a workshop method that bridges business and technical understanding through a shared visual notation

---

Proposed anchor file

= Event Storming according to Alberto Brandolini
:categories: requirements-engineering, software-architecture
:roles: software-architect, business-analyst, product-owner, consultant, team-lead
:related: domain-driven-design, user-story-mapping, cqrs, event-driven-architecture
:proponents: Alberto Brandolini
:tags: event-storming, ddd, domain-events, collaborative-workshop, bounded-contexts, aggregates, big-picture, design-level, process-modeling
:tier: 3

[%collapsible]
====
Full Name:: Event Storming according to Alberto Brandolini

Also known as:: EventStorming (one word, Brandolini's preferred spelling)

[discrete]
== *Core Concepts*:

Domain Events as starting point::
Everything begins with orange sticky notes representing Domain Events — facts that happened in the past tense ("Order Placed", "Payment Received", "Shipment Dispatched"). Events are the most stable element of a domain model because they represent observable facts, not interpretations.

Sticky note color taxonomy::
* **Orange** — Domain Event (past tense, something that happened)
* **Blue** — Command (imperative, triggers an event)
* **Yellow** — Aggregate (cluster of state + rules that decides whether a command succeeds)
* **Lilac/Purple** — Policy/Process Manager (automated reaction: "when X happens, do Y")
* **Green** — Read Model / Information (data needed to make a decision)
* **Pink** — External System (outside the bounded context)
* **Red/Pink rotating** — Hot Spot (unresolved question, conflict, confusion)
* **Large yellow** — Actor (person or role issuing commands)

Big Picture Event Storming::
Goal: explore the entire business domain in hours, not months. All domain experts in one room. Start with chaotic exploration (everyone writes events simultaneously), then organize into a timeline, identify swim lanes, mark pivotal events, and discover bounded context boundaries. Output: shared understanding, hot spots, and context boundaries.

Design Level Event Storming::
Goal: design the internals of a single bounded context. Start from the Big Picture boundary, then add Commands, Aggregates, Policies, and Read Models. Output: an aggregate design ready for implementation — including consistency boundaries and process flows.

Process Modeling Event Storming::
Goal: model a complex business process across multiple bounded contexts. Focus on the choreography between contexts via Domain Events and Policies. Output: integration map showing how contexts communicate.

The workshop flow::
1. **Chaotic exploration** — everyone writes events, no ordering (10-15 min)
2. **Enforce timeline** — left-to-right chronological ordering
3. **Identify pivotal events** — key state transitions that change everything
4. **Add commands and actors** — what triggers each event, who does it
5. **Add aggregates** — which cluster of state handles each command
6. **Add policies** — automated reactions connecting events to commands
7. **Mark hot spots** — unresolved conflicts, questions, disagreements
8. **Identify bounded contexts** — draw boundaries where language changes

[discrete]
== *When to Use*:

* Exploring a new or poorly understood domain before writing code
* Identifying bounded context boundaries for a microservice decomposition
* Onboarding new team members into domain complexity
* Discovering integration points between systems
* Planning migration of a monolith (map existing event flows first)
* **AI Agent Use Case:** Analyzing existing codebases through the Event Storming lens — identify state transitions as Domain Events, map side effects to Commands, cluster related events into Aggregate boundaries, discover implicit Policies. Output structured like a "virtual Event Storming" result.

[discrete]
== *When NOT to Use*:

* Simple CRUD applications with no complex domain logic
* When the domain is already well-understood and documented
* As a substitute for requirements workshops (Event Storming explores *what is*, not *what should be*)

[discrete]
== *Related Anchors*:

* <<domain-driven-design,Domain-Driven Design>> — Event Storming uses DDD vocabulary as its notation; DDD provides the strategic patterns that Event Storming helps discover
* <<user-story-mapping,User Story Mapping>> — complementary: USM maps user activities linearly; Event Storming explores domain events non-linearly
* <<cqrs,CQRS>> — Event Storming's Command/Event/Read Model separation maps directly to CQRS architecture
* <<event-driven-architecture,Event-Driven Architecture>> — Event Storming discovers the events; EDA decides how to route them
====

---

Proposed roles.yml entry

event-storming:
  roles:
    - software-architect
    - business-analyst
    - product-owner
    - consultant
    - team-lead
  rationale: "Collaborative domain discovery method; architects use it for bounded context identification, business analysts for domain exploration, product owners for shared understanding, consultants for facilitating workshops, team leads for onboarding and alignment"

---

Proposed translator catalog entry

| Event Storming according to Alberto Brandolini | Collaborative workshop method for domain discovery using colored sticky notes. Orange=Domain Event, Blue=Command, Yellow=Aggregate, Lilac=Policy. Three levels: Big Picture (domain-wide exploration), Design Level (single context internals), Process Modeling (cross-context choreography). Flow: Chaotic exploration → Timeline → Pivotal events → Aggregates → Bounded contexts. |

---

Next steps

If this direction is accepted, I can submit:

1. docs/anchors/event-storming.adoc (English)
2. docs/anchors/event-storming.de.adoc (German translation)
3. docs/metadata/roles.yml update
4. skill/semantic-anchor-translator/references/catalog.md update

---

Bewertung: Event Storming nach Alberto Brandolini als neuer semantischer Anker

(Deutsche Version)

---

Offene Fragen

1. Granularität: Big Picture vs. Design Level vs. Process Modeling. Brandolini unterscheidet drei Event-Storming-Varianten mit unterschiedlichen Zielen und Teilnehmerkreisen. Soll der Anker alle drei abdecken (Umbrella), oder nur Big Picture als eigenständiger Anker mit Design Level/Process Modeling als Sub-Anker? Da alle drei dieselbe Notation teilen (farbige Stickies), empfehle ich einen einzelnen Anker, der alle Varianten abdeckt, mit „Big Picture" und „Design Level" als Core Concepts.

2. Abgrenzung zu Domain-Driven Design. Event Storming ist eine Methode, DDD ist ein Framework. Die Methode setzt DDD-Vokabular voraus (Aggregates, Bounded Contexts, Domain Events). Soll Event Storming domain-driven-design als Voraussetzung oder als verwandten Anker referenzieren?

3. AI-Agenten-Anwendungsfall: Reverse Event Storming. Der Vorschlagende schlägt vor, einen AI-Agenten zur Analyse von Legacy-Code durch die Event-Storming-Linse zu nutzen. Dies ist ein umsetzbares Prompt-Pattern (Zustandsübergänge identifizieren → auf Domain Events abbilden → in Aggregates clustern → Bounded Contexts entdecken). Soll dies ein explizites „When to Use"-Szenario sein, oder ist es besser in einem separaten Skill aufgehoben?

---

Quellenverifikation

Ursprung: Alberto Brandolini, erstmals vorgestellt beim italienischen DDD-Community-Meetup 2012, Blogpost 2013.

Schlüsselpublikation: Alberto Brandolini, „Introducing EventStorming" (Leanpub, Eigenverlag, kontinuierlich aktualisiert seit 2013, ISBN 9781006258961)

Kanonischer Blogpost: http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html

Community-Adoption: Weit verbreitet in DDD-Communities, großer Konferenz-Circuit (DDD Europe, KanDDDinsky, Explore DDD). Zahlreiche abgeleitete Arbeiten von Vaughn Vernon, Nick Tune, Kenny Baas-Schwegler.

---

Bewertung gegen Qualitätskriterien

Kriterium	Urteil	Evidenz
Precise	✅	Spezifisches Workshop-Format mit definierter Notation: Orange=Domain Event, Blau=Command, Gelb=Aggregate, Lila=Policy, Grün=Read Model, Pink=Externes System, Rot/rotierend=Hot Spot. Drei unterschiedliche Levels (Big Picture, Design Level, Process Modeling) mit verschiedenen Zielen.
Rich	✅	Aktiviert: DDD-taktische Patterns, kollaborative Domänen-Entdeckung, Bounded-Context-Identifikation, Aggregate-Boundary-Design, Policy/Saga-Entdeckung, Integrationspunkt-Mapping, zeitlinienbasiertes Reasoning, chaotische Exploration → strukturiertes Modell.
Consistent	✅	Hohe LLM-Erkennung. Triggert konsistent die Sticky-Note-Taxonomie und den Workshop-Flow. Gut dokumentiert in Brandolinis Buch und Dutzenden Konferenzvorträgen.
Attributable	✅	Einzelner klarer Urheber: Alberto Brandolini (2012/2013). Keine Zuordnungsambiguität.

---

Lückenanalyse

Was der Katalog hat	Was Event Storming hinzufügt
domain-driven-design → strategische + taktische DDD-Patterns	Eine spezifische Methode um diese Patterns kollaborativ zu entdecken — das „Wie kommen wir zu Bounded Contexts"-Problem
event-driven-architecture → Architekturstil (async Messaging)	Die Modellierungstechnik die dem EDA-Design vorausgeht — entdecken welche Events existieren bevor entschieden wird wie sie geroutet werden
user-story-mapping → lineare Feature-Priorisierung entlang Backbone	Nicht-lineare Domänen-Exploration ausgehend von Events, nicht von Benutzeraktivitäten
cqrs → Command/Query-Segregation-Pattern	Event Storming entdeckt Commands und Queries bevor über CQRS-Architektur entschieden wird
(nichts)	Kollaboratives Domänen-Modelling als First-Class-Anker — eine Workshop-Methode die Business- und technisches Verständnis durch eine gemeinsame visuelle Notation verbindet

---

Vorgeschlagene Anchor-Datei

(Siehe englische Version oben)

---

Vorgeschlagener roles.yml-Eintrag

event-storming:
  roles:
    - software-architect
    - business-analyst
    - product-owner
    - consultant
    - team-lead
  rationale: "Kollaborative Domänen-Entdeckungsmethode; Architekten nutzen sie zur Bounded-Context-Identifikation, Business Analysten zur Domänen-Exploration, Product Owner für gemeinsames Verständnis, Berater zur Workshop-Facilitation, Team Leads für Onboarding und Alignment"

---

Vorgeschlagener Translator-Katalog-Eintrag

| Event Storming nach Alberto Brandolini | Kollaborative Workshop-Methode zur Domänen-Entdeckung mit farbigen Sticky Notes. Orange=Domain Event, Blau=Command, Gelb=Aggregate, Lila=Policy. Drei Ebenen: Big Picture (domänenweite Exploration), Design Level (Interna eines einzelnen Kontexts), Process Modeling (kontextübergreifende Choreographie). Flow: Chaotische Exploration → Zeitlinie → Pivotale Events → Aggregates → Bounded Contexts. |

---

Nächste Schritte

Falls diese Richtung akzeptiert wird, kann ich einreichen:

1. docs/anchors/event-storming.adoc (Englisch)
2. docs/anchors/event-storming.de.adoc (Deutsche Übersetzung)
3. docs/metadata/roles.yml Update
4. skill/semantic-anchor-translator/references/catalog.md Update

[raifdmueller]

Analysis — qualify ✅ (building on @JensGrote's assessment)

Agree fully with @JensGrote's criteria assessment (Precise/Rich/Consistent/Attributable all ✅) and source verification. Adding my take on the three open questions, since they're the decisions that block implementation:

1. Granularity → single umbrella anchor. Agree with Jens: one anchor "Event Storming" covering Big Picture / Process Modeling / Design Level as Core Concepts. The three share one notation (orange=Domain Event, blue=Command, yellow=Aggregate, lilac=Policy, green=Read Model, pink=External System, red=Hotspot) — splitting them would fragment a single activation. No sub-anchors needed.
2. Relation to DDD → related, not a hard prerequisite. Event Storming is often the on-ramp to DDD for teams that don't yet speak the language; making DDD a prerequisite understates that. Mutual related link with domain-driven-design.
3. Reverse Event Storming (AI legacy analysis) → include as a "When to Use" scenario. It's the proposer's primary use case and squarely on-brand for this project (prompt pattern: state transitions → Domain Events → Aggregates → Bounded Contexts). A dedicated skill can come later; the anchor should at least name the scenario.

Category: Jens' requirements-engineering, software-architecture fits (collaborative discovery + modeling). Recognition test passes strongly.

Verdict: qualify, ready to implement as a single umbrella anchor per Jens' draft. Thanks @SidekickJohn (and @JensGrote for the deep dive).

[raifdmueller]

Thanks @SidekickJohn! Event Storming according to Alberto Brandolini is now live (EN + DE), filed under Requirements Engineering and Software Architecture.

The anchor captures the full vocabulary: the colour notation (orange Event, blue Command, yellow Aggregate, lilac Policy, green Read Model, pink External System, red Hotspot), the three levels (Big Picture / Process Modeling / Design Level), pivotal events as bounded-context seams, hotspots, and Reverse Event Storming for reconstructing legacy systems. Merged in #569. 🙏

[SidekickJohn]

Thanks @JensGrote for the excellent work and thanks @raifdmueller for accepting! Nice and easy contribution workflow!