EventStorming: collaborative discovery, hotspots and testable hypotheses

Brandolini описывает EventStorming как collaborative modelling and deliberate collective learning. Big Picture исследует широкий domain flow, Process Modelling углубляет critical flow, Software Design помогает исследовать implementation boundaries. Результат workshop — shared understanding, questions и hypotheses; это не автоматический ready-to-code specification.

Что утверждает паттерн — и чего он не гарантирует

• EventStorming is collaborative learning/modelling; its value includes exposing inconsistencies, competing goals and impediments.
• Big Picture, Process Modelling and Software Design are formats with different scope/depth, not automatic stages of a delivery pipeline.
• Past-tense events represent business facts; commands are intent, policies/reactions connect facts to possible next intent.
• Incremental notation and hotspots preserve flow and uncertainty; polished deliverables are not the primary guarantee.

Границы и компоненты

Сценарии

Explore the Big Picture

Participants begin with past-tense events across a broad timeline, tell the story aloud and mark conflicts or missing knowledge as hotspots before adding precision.

Проверяемый исход: The session produces shared questions and pivotal flows without forcing premature implementation detail.

Model a critical process

A smaller group explores Order Submitted, payment authorization and fulfillment reactions with actors, commands, policies and exception paths.

Проверяемый исход: Happy path and edge cases remain hypotheses until concrete examples and domain experts validate them.

Derive software-design hypotheses

Commands/events/policies suggest aggregate and integration candidates. The team checks invariants, transaction need and external failure before drawing deployables.

Проверяемый исход: Aggregate/service boundaries are reviewable candidates, not workshop-certified production architecture.

Validate hotspots with examples

The team turns disputed rules, duplicate commands, payment timeout and compensation into acceptance examples; architecture decisions record only resolved semantics.

Проверяемый исход: Unresolved questions stay explicit, and no sticky-note flow is called executable until tested.

Failure, concurrency и evolution checklist

• Invite relevant domain perspectives and say the story aloud to expose disagreements.
• Keep uncertain external outcomes and exception paths as hotspots until validated.
• Convert critical rules into examples/acceptance tests before implementation.
• Record transaction, idempotency, messaging and ownership decisions separately from workshop notation.

Метрики, units и допущения

• Workshop time-box and participant count are facilitation choices, not proof of coverage.
• Track unresolved hotspots by risk/owner/review date rather than declaring the model complete.
• Event ordering on a wall is a domain narrative; it does not define milliseconds, broker order or delivery semantics.

Числа здесь — размерностные формулы или явно помеченные учебные inputs. Паттерн архитектуры сам по себе не задаёт SLA, throughput, latency или fault tolerance.

Связанные темы

[CONCEPT]ddd-strategic

[CONCEPT]ddd-tactical

Первичные источники

• https://www.eventstorming.com/
• https://www.eventstorming.com/book/
• https://www.eventstorming.com/resources/
• https://www.eventstorming.com/patterns/incremental-notation/

Scope note

This is a workshop/discovery model. It does not itself specify storage, transactions, broker semantics, authorization, deployment, SLOs or production correctness; those require subsequent decisions and tests.