event-storming.js·3 scenarios
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.
Главная проблема в начале большого проекта — никто не понимает домен целиком. Бизнес знает workflow, разработчики — код, аналитики — данные, продакт — рынок. Каждый видит свой кусок, никто — карту. В результате архитектура рождается из догадок, через год оказывается, что половина инвариантов не закодирована, а половина закодированных правил никому не нужна.
Event Storming (Alberto Brandolini, 2013) — workshop-техника, где за 2-4 часа на стене из стикеров команда собирает общую карту домена. Это самый быстрый известный способ из «5 экспертов с противоречащими ментальными моделями» сделать «5 экспертов, у которых на стене одна общая модель». Главный артефакт — не диаграмма, а shared understanding.
Бизнес-процесс — это последовательность событий, которые произошли. Если 5-10 экспертов соберутся у стены, расклеят все события в timeline и пройдут его сверху вниз, через 2 часа станет видно: дыры, противоречия, естественные границы контекстов и кто на самом деле инициирует каждое действие.
Три уровня глубины (выбирается под цель сессии):
| Уровень | Цель | Что добавляется | Время |
|---|---|---|---|
| Big Picture | Понять весь домен и его границы | Только оранжевые события + розовые hotspots | 2-4 часа |
| Process Modelling | Проработать конкретный business process (checkout, refund) | + actors, commands, policies, read models | 4-8 часов |
| Software Design | Спроектировать bounded context для имплементации | + aggregates, external systems | день |
Canonical color code (нарушать только осознанно — это lingua franca DDD-сообщества):
| Цвет | Что | Пример |
|---|---|---|
| Оранжевый | Domain Event (past tense) | OrderPlaced, PaymentReceived |
| Синий | Command | PlaceOrder, ChargeCard |
| Жёлтый | Actor / User | Customer, Admin, System |
| Розовый | Hot spot / problem | Вопросы, противоречия, риски |
| Фиолетовый | Policy / Business rule | «Когда X, то Y» |
| Зелёный | Read Model | Что нужно увидеть для решения |
| Светло-голубой | External system | Stripe, SendGrid, DHL |
| Светло-жёлтый | Aggregate (design-level) | Cart, Order, Payment |
Шаги канонической сессии: Chaotic Exploration → Enforce Timeline → People & Systems → Walk the Wall (reverse narrative) → Identify Bounded Contexts → (опционально) Commands + Aggregates.
E-commerce домен после трёх итераций Event Storming, схлопнутый в три emerging bounded contexts:
И два hotspot (красные ноды):
HOTSPOT: who triggers shipping? — после OrderPlaced никто не знает, кто инициирует PickAndPack. Customer? Worker? Cron? Workshop не решает, фиксирует.HOTSPOT: refund flow undefined — PaymentFailed открывает вопрос компенсирующих транзакций, который команда не успела продумать.Handoff между контекстами происходит на pivotal events — CheckoutStarted отдаёт управление из Sales в Payments, PaymentSucceeded из Payments в Fulfillment. Это не случайность: pivotal events почти всегда оказываются естественными границами bounded contexts. Когда меняется язык (Cart → Payment → Order), меняется и команда, которая владеет контекстом.
Big Picture session. Так начинается любой EventStorming: ведущий выдаёт всем оранжевые стикеры, объявляет «пишем всё, что happens в нашем домене, past tense, по одному событию на стикер» и 20-30 минут хаоса — никакого ordering, никакого согласования, просто вылить из головы. Потом начинается Enforce the Timeline: события сортируются слева направо хронологически, дубликаты схлопываются, споры → розовый стикер. На большом домене после этого шага стена в 8-10 метров уже даёт ощущение «вот это масштаб системы». Pivotal events (CheckoutStarted, PaymentSucceeded, OrderPlaced) проявляются естественно — это места, где storyline резко меняет направление.
Design-level session. Когда Big Picture готов, команда выбирает ОДИН bounded context (обычно самый рискованный) и идёт глубже. Добавляются синие commands («что должно произойти, чтобы вылез этот event?»), жёлтые actors («кто инициирует команду?»), светло-жёлтые aggregates (boundaries консистентности — что должно быть атомарно изменено для эмиссии события?), фиолетовые policies («когда X произошёл, автоматически делаем Y»). Результат для Sales: Customer → AddItem (cmd) → Cart (agg) → ItemAdded (evt) + policy: cart TTL 24h. Это уже ready-to-code модель — её можно положить рядом с клавиатурой и начать писать handlers.
Hot spots + context boundaries. Самая ценная фаза. Команда делает Walk the Wall — идёт от конца истории назад («чтобы произошла Delivery, что должно было случиться раньше?») и на каждом шаге проверяет: достаточно ли тут информации? кто это запускает? что если шаг провалится? Каждое «не знаю» → розовый стикер. На диаграмме видны два: who triggers shipping? (между OrderPlaced и PickAndPack) и refund flow undefined (после PaymentFailed). EventStorming не решает эти вопросы — он их обнаруживает до того, как они превратились в production-инциденты. Параллельно проявляются bounded contexts: где меняется язык (Cart vs Payment vs Order), где меняется частота событий, где другой actor — там граница. Output workshop: 3 bounded contexts + 2 hotspots + общий ubiquitous language.
Решение: проводить Big Picture EventStorming перед началом значимой работы над сложным доменом.
За:
Против:
Когда выбирать EventStorming: complex/новый домен, re-architecture монолита, понимание legacy перед refactor, onboarding новой команды, после смены стратегии. Когда не выбирать: простой CRUD, well-known domain (третья реализация blog engine), команда из 1-2 человек (нет противоречий, которые нужно выровнять).
Add Item вместо Item Added). Грамматика важна: события в past tense, команды в imperative. Это не педантизм — это разница между «что хотели» и «что произошло».