System Design Cases
Event Storming
Event Storming workshop technique by Alberto Brandolini for domain discovery. Three bounded contexts (Sales, Payments, Fulfillment) with domain events, commands, aggregates, policies, external systems, actors, and hot spots. Multi-scenario animation showing big-picture chaotic exploration, design-level deep dive, and how hot spots and bounded context boundaries emerge from pivotal events.
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.
Границы и компоненты
| Компонент | Ответственность |
|---|---|
| Domain Experts and Facilitator | Рассказывают разные perspectives и управляют discovery format. |
| Past-Tense Domain Event Timeline | Показывает значимые business facts во времени. |
| Commands and Actors | Объясняет intent и кто/что инициирует изменения. |
| Policies and Reactions | Связывает event с последующей command как hypothesis. |
| Aggregate Candidates | Кандидаты consistency/behavior boundaries для validation. |
| External Systems | Отмечает чужие protocols, latency и failure uncertainty. |
| Hotspots and Open Questions | Сохраняет disagreement, exception и риск вместо premature certainty. |
| Examples and Acceptance Tests | Проверяет выбранные rules/corner cases после workshop. |
| Architecture Decisions | Фиксирует verified transaction, messaging и ownership choices. |
Сценарии
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.
Связанные темы
Первичные источники
- 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.