Event Storming: workshop для DDD-спецификации

Полный гид по Event Storming как технике сбора данных для DDD-спецификации. Три уровня (Big Picture, Process, Design), пошаговый workshop на маркетплейсе, маппинг артефактов в 16 разделов спеки, антипаттерны, чек-лист facilitator-а.

DDD-спецификация в нашей методологии — это 16 разделов, от Bounded Context до Нефункциональных требований. Каждый раздел требует данных. Откуда их брать?

Самый болезненный путь — садится разработчик с бизнес-аналитиком, и они вместе три недели «выясняют требования». Аналитик задаёт вопросы по списку, разработчик кивает, потом каждый пишет своё. Через месяц выясняется, что они говорили о двух разных системах. Знакомо.

Самый правильный путь — Event Storming. Это workshop, придуманный Alberto Brandolini в 2013, который за 4-8 часов выдаёт большую часть данных для спеки сразу: события, команды, акторы, агрегаты, бизнес-правила, проблемные места. Не идеально, но в десять раз быстрее интервью-по-списку.

Эта статья — полный гид:

Что такое Event Storming и какие у него три уровня (Big Picture / Process / Design)
Кого звать на workshop, что готовить, сколько по времени
Цветовой код, нотация, последовательность шагов
Сквозной пример: проводим Event Storming на маркетплейсе из нашего кейса и приходим к спеке Order Service
Маппинг каждого артефакта Event Storming в конкретный раздел спеки (1-16)
Антипаттерны: что разваливает workshop, как этого избежать
Онлайн, гибрид, асинхронный варианты
Чек-лист facilitator-а

Цель статьи — чтобы после неё вы могли провести Event Storming в своей команде сами, и его выход легко превратился в Tier B или Tier C спеку. Без книжек, без курсов, без консультантов.

Зачем Event Storming, если можно интервью

Я в разное время использовал и интервью, и user story mapping, и domain storytelling, и event storming. Разница такая:

Интервью даёт список вопросов от разработчика к бизнесу. Каждый ответ — отдельная клеточка в чьей-то голове. Связи между ответами строит уже разработчик в одиночку. Отсюда классическая ошибка: «А мы что, должны были учесть отмену заказа после оплаты? Об этом никто не говорил». Никто, потому что никто не спросил, потому что разработчик не знал, что нужно спрашивать.

User story mapping хорош для UX и фич, но плохо ловит что происходит между фичами — отмены, возвраты, time-based-переходы, асинхронные последствия. Он про активные действия пользователя, а не про систему как процесс.

Domain storytelling очень близок к Event Storming, но работает через рассказ от первого лица: «продавец заходит, добавляет товар, потом покупатель…». Сильная техника, но требует сильного фасилитатора и плохо параллелизуется (рассказывать может один за раз).

Event Storming работает иначе. Все участники одновременно вываливают на доску события — то, что фиксированно происходит в бизнесе. Не «процессы», не «фичи», не «истории», а отдельные факты прошедшего времени: «Заказ оплачен», «Спор открыт», «Продавцу выплачены деньги». Затем эти события упорядочиваются в последовательность, и вокруг них наматывается всё остальное: кто их вызвал, какая команда привела к событию, какая внешняя система вовлечена, какое бизнес-правило применилось.

Event Storming эффективен потому что:

События — это самая стабильная сущность бизнеса. Меняются процессы, меняется UI, меняются интеграции. А «заказ оплачен» как факт — он или произошёл, или нет, и это не зависит от технологии.
Команда работает параллельно. Каждый клеит свои стикеры, не ждёт очереди. За первые 30 минут на доске появляются 100-200 событий — обзор полнее, чем после трёх дней интервью.
Конфликты вылезают наружу сразу. Если у БА в голове «заказ оплачен» наступает после клика «Купить», а у разработчика — после подтверждения от банка, на доске эти два стикера встретятся и спор поднимется в первый час, а не через месяц.
Получается живая карта. После workshop у вас на руках не текст с пропусками, а структурированный артефакт, который один в один ложится в DDD-спеку.

Когда не подходит: проект с одним актором и тремя кнопками; команда, в которой никто не понимает бизнес и звать некого; распределённая команда без хорошего онлайн-инструмента (Miro/Mural). В остальных случаях — самый эффективный способ собрать данные для спеки.

Три уровня Event Storming

Brandolini выделил три уровня детализации. Они не альтернативны — это шаги от обзорного к детальному. Мы прогоняем все три за разные сессии или за один длинный день.

Уровень 1: Big Picture

Цель: понять весь бизнес целиком. Все события, все акторы, все внешние системы. Без техники, без агрегатов, без правил.

Кого звать: бизнес (заказчик, продакт, БА), архитектор, тимлид. По возможности — два-три ключевых разработчика, которые потом будут реализовывать.

Время: 2-4 часа. Один длинный сеанс.

Выход:

Полный список доменных событий
Hot spots (вопросы, конфликты, неясности)
Pivotal events (ключевые точки, по которым процесс делится на стадии)
Первичная разбивка на Bounded Contexts
Внешние системы

Что попадает в спеку: разделы 1 (Bounded Context), 8 (Domain Events), 14 (Интеграции), частично 16 (Open Questions / Risks).

Уровень 2: Process Level

Цель: для каждого Bounded Context, выявленного на Big Picture, прорисовать как именно идёт процесс. Какие команды вызывают какие события, кто их инициирует, какие политики срабатывают.

Кого звать: те же плюс UX-дизайнер (если есть UI), плюс QA для критериев приёмки.

Время: 1-2 часа на контекст. Для маркетплейса с 5-7 контекстами — это 1-2 рабочих дня в сумме.

Выход:

Для каждого процесса: цепочка Actor → Command → Aggregate → Event → Policy → Command → ...
Read Models (что нужно показывать, чтобы команды могли срабатывать)
Уточнённые роли и права
Бизнес-правила в местах принятия решений

Что попадает в спеку: разделы 5 (Роли), 6 (Бизнес-правила), 7 (Commands), 9 (Read Model), 10 (Use Cases), 12 (Saga / Process Manager).

Уровень 3: Design Level

Цель: для критичных Bounded Contexts проработать внутреннее устройство агрегатов — какие у них инварианты, состояния, переходы.

Кого звать: архитектор, разработчики этого контекста. Бизнес уже не нужен — это про код.

Время: 2-3 часа на агрегат.

Выход:

Состав агрегата (сущности, value objects)
Инварианты, которые он обеспечивает
Жизненный цикл и матрица переходов
Команды, которые он принимает; события, которые он публикует

Что попадает в спеку: разделы 3 (Domain Model), 4 (Жизненный цикл и состояния), 6 (Бизнес-правила и инварианты — детальные), 13 (Каталог ошибок).

Цветовой код и нотация

Цвета стикеров — это договорённость, не закон. Большинство команд использует вариацию того, что предложил Brandolini. Я опишу схему, которая лучше всего ложится на нашу 16-разделочную спеку, и далее в примерах буду использовать именно её.

Цвет	Что означает	Форма	Пример
Оранжевый	Domain Event — факт прошедшего времени	Прямоугольник	«Заказ создан», «Платёж подтверждён»
Голубой	Command — императивный глагол	Прямоугольник	«Создать заказ», «Подтвердить платёж»
Жёлтый (малый)	Actor — роль, инициировавшая команду	Маленький квадратик слева от команды	«Покупатель», «Продавец», «Оператор»
Розовый	External system — внешняя система	Большой прямоугольник	«Платёжный шлюз», «Логистика»
Сиреневый	Policy — «когда это событие, тогда эта команда»	Прямоугольник между event и command	«Когда заказ оплачен, отправить уведомление продавцу»
Зелёный	Read Model / View — данные, по которым актор принимает решение	Прямоугольник перед командой	«Витрина каталога», «Список заказов продавца»
Жёлтый (большой)	Aggregate — то, что обеспечивает инвариант	Большой жёлтый, объединяет команды/события	«Order», «Cart», «Dispute»
Красный	Hot spot — конфликт, вопрос, неясность	Прямоугольник или восклицательный знак	«Что считаем "оплатой"? Списание или подтверждение?»
Розовый узкий	Pivotal event — ключевая точка процесса	Узкий вертикальный	«Заказ оплачен» (делит процесс на «до оплаты» и «после»)

Для онлайн-версии в Miro/Mural есть готовые шаблоны Event Storming с этими цветами. В офлайн — берёте обычные стикеры IKEA, главное чтобы у каждого цвета был однозначный смысл, объявленный в начале workshop.

Главное правило именования:

События пишутся в прошедшем времени, страдательном залоге: «Заказ оплачен», не «Оплата заказа», не «Оплатить заказ». Это критично — путаница тут разваливает workshop.
Команды пишутся в инфинитиве: «Создать заказ», «Подтвердить платёж».

Подготовка workshop

Что нужно

Офлайн:

Стена 4-6 метров (или склеенная бумага). Главное — длинная горизонталь, потому что timeline идёт слева направо.
Стикеры разных цветов. Минимум 500 оранжевых, 200 каждого из остальных.
Маркеры. По одному на участника, лучше тонкие (на стикере места мало).
Скотч или магниты — для связей между стикерами.
Камера для фотографий доски на каждом этапе. После workshop вы оцифруете в Miro.

Онлайн:

Miro / Mural / Lucidchart с шаблоном Event Storming. У всех трёх есть готовые шаблоны.
Видеозвонок с включёнными камерами всех участников. Без камер не работает — теряется ощущение совместной работы.
Один человек = один курсор. Максимум 8-10 участников онлайн (больше — тонут в шумах).

Кого звать

Уровень	Бизнес/PO	БА	Архитектор	Тимлид	Разработчики	UX	QA
Big Picture	Обязательно	Обязательно	Обязательно	Желательно	2-3 ключевых	—	—
Process	Желательно	Обязательно	Обязательно	Обязательно	По контексту	Если есть UI	Желательно
Design	—	—	Обязательно	Обязательно	Обязательно	—	—

Не зовите на Big Picture и Process: всех джунов, тестировщиков мобильных приложений, бухгалтерию, маркетинг. Они не страдают, но workshop тонет в шуме. Им устройте обзорную сессию по итогам — отдельно.

Размер группы: оптимально 6-8 человек. Меньше четырёх — теряется коллективный эффект (мало стикеров = мало мысли). Больше двенадцати — теряется возможность держать общее внимание.

Что подготовить заранее

Бизнес-описание на 1-3 страницы в формате нашего кейса маркетплейса — без архитектурных терминов, своими словами. Это не TЗ, а контекст. Раздать за 2-3 дня до workshop.
Глоссарий того, что уже понятно: участники, ключевые сущности. Мы выложили пример для маркетплейса — это образец того, как должен выглядеть глоссарий до workshop. После — он расширится в раздел Ubiquitous Language спеки.
Time-box-расписание: сколько времени на каждый шаг. Без жёсткого тайминга workshop затянется.
Правила: «события в прошедшем времени», «не спорим в первый час, только клеим», «один стикер — один факт». Распечатать и повесить на видном месте.

Шаг за шагом: Big Picture для маркетплейса

Дальше — реальный proходка workshop на нашем кейсе маркетплейса. Я веду как facilitator. На входе — бизнес-описание из кейса (3 страницы про маркетплейс) и глоссарий (товар, корзина, заказ, платёж, возврат, спор, комиссия, промокод). На выходе должны получиться данные для разделов 1, 8, 14, 16 спеки.

Шаг 1: Chaotic Exploration (40 минут)

Команда фасилитатору: «Сейчас 30 минут. Вспоминайте всё, что в маркетплейсе происходит как факт прошедшего времени. Не процессы, не действия — а свершившиеся события. Один стикер — одно событие. Не пытайтесь упорядочить, не задумывайтесь о связях. Клейте на стену в случайных местах.»

Это работает: команда молчит и просто пишет. Через 30 минут на стене 150-300 оранжевых стикеров.

Что появляется на маркетплейсе:

Карточка товара создана      Заказ создан         Платёж принят
Товар одобрен модератором    Промокод применён    Платёж не прошёл
Карточка отклонена           Корзина очищена      Заказ оплачен
Товар добавлен в корзину     Заказ отменён        Деньги списаны
Покупатель залогинился       Курьер назначен      Заказ собран
Продавец зарегистрирован     Заказ доставлен      Покупка получена
Оператор подтвердил спор     Спор открыт          Возврат начат
Деньги возвращены покупателю Спор закрыт          Расчёт продавцу выполнен
Комиссия удержана            Отзыв оставлен       Карточка скрыта
... и ещё ~150 стикеров

Оранжевый шторм. На этом этапе нет вопросов «правильно ли это написано», нет «а это уже было», нет дискуссий. Только стикеры.

Шаг 2: Enforcing the Timeline (40 минут)

Дальше команда вместе упорядочивает события слева направо по времени. Появляется timeline.

Здесь начинаются первые споры. И это хорошо — споры в этот момент дешевле, чем после старта разработки.

Например, два стикера: «Заказ оплачен» и «Платёж принят». Покупатель кликает «Купить», вводит карту, всё проходит. В какой момент заказ «оплачен»?

Версия БА: «Когда покупатель ввёл карту и нажал Купить — это и есть оплата».
Версия архитектора: «Это попытка оплаты. Платёж принят — это когда банк подтвердил списание. Заказ оплачен — это когда платёж принят и применён к заказу».

Это первый Hot Spot (красный стикер на доске): «Что значит "заказ оплачен"? До этого момента у нас в системе будет два состояния — pending и paid. Между ними может пройти 30 секунд, может 30 минут, может час.»

Записываем в hot spot и идём дальше. Не решаем сейчас.

После упорядочивания получается примерно такая последовательность (для процесса покупки):

Карточка товара     Покупатель    Промокод       Заказ      Платёж      Платёж        Заказ      Курьер     Заказ      Покупка
создана             зарегистрирован применён       создан     инициирован принят         оплачен    назначен   доставлен  получена
   (продавец)        (покупатель)   (покупатель)  (покупатель)            (платёжный    (Order BC)            (логистика) (покупатель)
                                                                          шлюз)

В аналогичные дорожки складываются: процесс возврата, процесс спора, процесс расчёта продавцу, процесс модерации.

Шаг 3: People & Systems (30 минут)

Теперь к каждому событию слева приклеиваем жёлтый стикерик — кто инициатор. Если инициатор — внешняя система, клеим розовый. Если событие — следствие другого события без участия человека (триггерит сама система через политику), оставляем без актора.

Маркетплейс быстро показывает четыре главных типа акторов:

Покупатель — инициирует «Заказ создан», «Платёж инициирован», «Покупка получена», «Спор открыт»
Продавец — «Карточка создана», «Заказ собран», «Возврат принят»
Оператор — «Карточка одобрена», «Спор закрыт» (после модерации)
Внешние системы: «Платёжный шлюз» (события «Платёж принят», «Платёж не прошёл»), «Логистика» (события «Курьер назначен», «Заказ доставлен»)

Появляются и события без актора: «Промокод применён» — это не действие пользователя в чистом виде, это политика «когда корзина обновлена, проверь применимые промокоды». Помечаем сиреневым стикером — будем дорабатывать на Process Level.

Шаг 4: Walk Through (20 минут)

Facilitator ведёт пальцем по timeline и вслух читает все события подряд. «Карточка товара создана. Карточка одобрена модератором. Покупатель залогинился. Товар добавлен в корзину. Промокод применён. Заказ создан. Платёж инициирован.» И так далее.

В этот момент все замечают пропуски и нелогичности. «Стоп, а где "Карточка отображена в выдаче"? У нас от создания до добавления в корзину три месяца может пройти. Ну нет, "Отображена" — это не событие, это состояние. Тогда нужен стикер "Карточка попала в индекс поиска"». И так далее.

Walk through — это самый важный шаг. Без него часть событий остаётся пропущенной.

Шаг 5: Pivotal Events (20 минут)

Из всей timeline команда выбирает 5-9 ключевых событий — таких, после которых в бизнесе происходит качественный сдвиг. Это будущие границы между Bounded Contexts и границы между состояниями агрегатов.

Для маркетплейса pivotal events:

Карточка одобрена — товар становится виден на витрине
Заказ создан — корзина превращается в финансовый документ, остатки резервируются
Заказ оплачен — деньги физически у платформы, можно отгружать
Заказ доставлен — курьерская часть закрыта, начинается зачёт продавцу
Покупка получена — точка невозврата для отмены, открывается окно споров
Спор открыт — деньги замораживаются, привлекается оператор
Спор закрыт — деньги либо к продавцу, либо к покупателю
Расчёт продавцу выполнен — деньги физически ушли к продавцу

Эти pivotal events рисуем жирной вертикальной чертой через всю timeline. Глядя на них, видно: бизнес делится на стадии «До модерации», «На витрине», «Заказ → Оплата», «Доставка → Получение», «Споры/Возвраты», «Расчёт».

Шаг 6: Bounded Contexts (30 минут)

Теперь команда обводит группы стикеров на timeline в большие овалы — это кандидаты в Bounded Contexts.

Для маркетплейса естественно получаются:

Bounded Context	События в нём	Кто владелец
Catalog	Карточка создана, одобрена, отклонена, отображена в выдаче	Команда продавцов
Cart	Корзина создана, товар добавлен/убран, промокод применён	Команда покупателей
Order	Заказ создан, заказ оплачен, заказ отменён, заказ доставлен	Команда продавцов
Payment	Платёж инициирован, принят, не прошёл, возврат сделан	Платежная команда
Delivery	Курьер назначен, заказ собран, доставлен, получен	Логистика (часто внешняя)
Dispute	Спор открыт, передан оператору, закрыт	Команда поддержки
Settlement	Комиссия удержана, расчёт продавцу выполнен	Финансовая команда
Moderation	Карточка одобрена/отклонена, продавец заблокирован	Команда модерации

Ровно эти контексты и появились в спеке Order Service с обозначениями соседних контекстов.

Шаг 7: Hot Spots (10 минут)

Перед закрытием Big Picture отдельно собираем все красные стикеры в одном месте — список открытых вопросов. Для маркетплейса:

Что считаем «заказ оплачен» — попытка или подтверждение от банка? Решение: подтверждение.
Можно ли отменить заказ после оплаты, но до доставки? Решение: да, с возвратом.
Что происходит с резервом товара, если оплата висит >30 минут? Решение: автоматический unreserve.
Может ли продавец быть одновременно покупателем? Решение: нет, разные кабинеты.
Идемпотентность повторного клика «Купить» — что считаем дубликатом? Hot spot, идёт в раздел 16 спеки.

Hot spots, по которым решение не принято, попадают в раздел 16 спеки (Open Questions/Risks) с явным указанием — что должно произойти, чтобы решение было принято (кто отвечает, к какому сроку).

Process Level: процесс заказа в Order контексте

После Big Picture делаем перерыв и берём один из выявленных Bounded Contexts — Order. На него закладываем 1-2 часа отдельной сессии.

Цель — для каждого события и команды выстроить связи:

[Read Model] → [Actor] → [Command] → [Aggregate] → [Event] → [Policy] → [Command] → ...

Пример для Order:

Создание заказа:

[Витрина каталога] → [Покупатель] → [Создать заказ] → {Order} → «Заказ создан» 
                                                                      ↓
                                                          [Policy: Зарезервировать остаток]
                                                                      ↓
                                                                [Зарезервировать]
                                                                      ↓
                                                                {Inventory} → «Остаток зарезервирован»

Оплата заказа:

[Список заказов] → [Покупатель] → [Оплатить заказ] → {Order} → «Платёж инициирован»
                                                                      ↓
                                                          [Policy: Запросить списание]
                                                                      ↓
                                                                {Платёжный шлюз}
                                                                      ↓
                                                          «Платёж принят» / «Платёж не прошёл»
                                                                      ↓
                                                          [Policy: Применить платёж к заказу]
                                                                      ↓
                                                          [Подтвердить оплату заказа]
                                                                      ↓
                                                                {Order} → «Заказ оплачен»

В процессе вылавливаются:

Бизнес-правила на стрелках: «Заказ можно оплатить только в статусе pending», «Сумма платежа = сумма заказа после применения промокода». Это раздел 6 спеки.
Read Models перед командами: «Витрина каталога» с фильтрами, наличием, ценой; «Список заказов» с пагинацией. Это раздел 9.
Use cases как полные цепочки: «Покупка от создания заказа до получения», «Возврат после доставки». Это раздел 10.
Saga — длинные процессы, где много событий и политик: «Order Saga» (от создания до расчёта). Это раздел 12.

В реальности на Process Level появляются матрицы переходов — какие команды разрешены в каждом состоянии заказа. Это уже раздел 4 спеки Order Service — табличка OrderStatus × команда.

Design Level: внутренности агрегата Order

Третий уровень — детальная проработка одного агрегата. Проходим за 2-3 часа с архитектором и 2-3 разработчиками. Бизнес уже не нужен.

Цель — для агрегата Order:

Состав:
- Корневая Entity: Order (id, status, buyerId, sellerId, items, totalAmount, ...)
- Вложенные сущности: OrderItem (productId, quantity, price, ...)
- Value Objects: Money, Address, OrderStatus
Инварианты, которые агрегат поддерживает:
- «Заказ нельзя оплатить дважды»
- «Сумма заказа = сумма позиций минус скидка»
- «Заказ нельзя отменить после доставки»
- «Количество товара в позиции > 0»
Жизненный цикл:
- Состояния: pending → paid → shipped → delivered → completed
- Альтернативные ветки: cancelled, refunded, disputed
- Time-based переходы: pending → expired через 30 минут
Команды (методы агрегата):
- place(items, buyer) → событие «Заказ создан»
- applyPayment(payment) → событие «Заказ оплачен» или ошибка
- cancel(reason) → событие «Заказ отменён» или ошибка (если уже доставлен)
- И так далее
События (что агрегат публикует):
- OrderCreated, OrderPaid, OrderCancelled, OrderShipped, OrderDelivered
Каталог ошибок:
- OrderAlreadyPaidException, CannotCancelDeliveredOrderException, InsufficientStockException

Всё это — прямой вход в разделы 3, 4, 6 (детальные), 7, 8, 13 спеки. После Design Level спека Order Service практически готова — остаётся UI (раздел 11), критерии приёмки (15), НФТ (16) и интеграции (14, частично уже выявлено на Big Picture).

Маппинг артефактов в 16 разделов спеки

Сводная таблица — какой шаг Event Storming даёт данные для какого раздела спеки. Это главная ценность статьи: теперь у вас есть workflow от workshop до спеки без пропусков.

№	Раздел спеки	Уровень ES	Какие стикеры используем
1	Bounded Context	Big Picture	Овалы вокруг групп событий, pivotal events как границы
2	Ubiquitous Language	Big Picture	Из подготовки + спорные термины из Hot Spots
3	Domain Model	Design	Жёлтые большие (Aggregates) + сущности и VO внутри
4	Жизненный цикл и состояния	Process + Design	Цепочки событий, pivotal events как границы состояний
5	Роли и права доступа	Big Picture + Process	Жёлтые малые (Actors) + права на каждую команду
6	Бизнес-правила и инварианты	Process + Design	Сиреневые (Policies) + правила-условия на стрелках
7	Commands	Process	Голубые (Commands) с подписанными акторами
8	Domain Events	Big Picture + Process	Оранжевые (Events) — основной артефакт ES
9	Queries / Read Model	Process	Зелёные (Read Models) перед командами
10	Use Cases	Process	Полные цепочки от Read Model до конечного события
11	UI-спецификация	Process (с UX)	Read Models = экраны, состояния агрегата = вкладки
12	Saga / Process Manager	Process	Длинные цепочки с политиками между контекстами
13	Каталог ошибок	Design	Из инвариантов агрегата — что нарушается
14	Интеграции (Context Mapping)	Big Picture	Розовые (External systems) + связи между контекстами
15	Критерии приёмки	Process (с QA)	Из use cases — наблюдаемые финальные события
16	НФТ + Open Questions	Big Picture	Красные (Hot Spots) — то, что не решилось

Покрытие: один проход всех трёх уровней Event Storming за 6-10 часов чистого workshop-времени даёт данные для 15 из 16 разделов спеки. Один раздел (15. Критерии приёмки) обычно дописывается отдельной сессией с QA — но и она опирается на Process Level Event Storming.

Антипаттерны и грабли

Семь самых частых ошибок в Event Storming, по моему опыту проведения workshop в банках, маркетплейсах и государственных IT.

1. «Event Storming для всего проекта целиком на одной доске»

Происходит, когда фасилитатор хочет «увидеть систему целиком», и не делит на контексты. К концу Big Picture на доске 800 стикеров, понять что-либо невозможно.

Лечение: Big Picture даёт первичную разбивку на контексты. Дальше Process Level ведётся отдельно по контексту, своя доска, свой workshop. Не пытайтесь одним движением проработать весь маркетплейс.

2. Технические термины вместо событий

«Сохранён в БД», «Отправлен в Kafka», «Cache invalidated». Это не доменные события, это технические артефакты реализации. Бизнес о них не знает и знать не должен.

Лечение: правило facilitator-а — «событие — это то, что заметит бизнес-стейкхолдер на своём интерфейсе или в отчёте». «Заказ оплачен» — да. «Запись в orders table обновлена» — нет.

3. Один человек диктует, остальные молчат

Чаще всего диктует архитектор или ведущий разработчик. Workshop превращается в монолог с покивыванием.

Лечение: на Шаге 1 (Chaotic Exploration) facilitator прямо говорит: «30 минут все молчат и пишут стикеры. Никаких обсуждений». Если кто-то начинает вслух — остановить. Это работает: даже самые тихие за 30 минут наклеят свои 15-20 стикеров.

4. Слишком детальная проработка на Big Picture

Команда ныряет в реализацию: «А как мы будем хранить статус заказа?», «А Kafka или RabbitMQ?». На Big Picture это убийственно.

Лечение: facilitator повторяет: «Это будет на Process Level / на Design Level. Сейчас только бизнес-факты». Технические идеи — на отдельном стикере «Parking lot», вернёмся к ним позже.

5. Игнорирование Hot Spots

Команда дружно избегает красных стикеров — там сложно, спорно, неуютно. Workshop проходит «гладко», все довольны. А через месяц реализации hot spot всплывает как блокирующая проблема.

Лечение: в конце Big Picture обязательно проходим по красным стикерам, на каждый есть план: либо решение принято здесь, либо явный owner и срок («бизнес-аналитик уточнит у заказчика к пятнице»). Раздел 16 спеки — последняя линия обороны от пропущенных hot spots.

6. Бесконечный workshop без time-boxing

«Давайте ещё 30 минут… ну ещё чуть-чуть». Через 6 часов команда мертва, последние 2 часа дают -50% к общему результату.

Лечение: жёсткие тайм-боксы, объявленные заранее. 30 + 30 + 20 + 30 + 20 + 20 + 30 + 10 = 3 часа Big Picture. Перерыв 30 минут. Дальше Process Level — но это другой день, не сегодня. Усталость = плохие данные.

7. Workshop без подготовки

Команда садится без бизнес-описания и глоссария. Первый час уходит на «расскажите, что у нас вообще за продукт». Это интервью, не Event Storming.

Лечение: бизнес-описание образца кейса маркетплейса — за 2-3 дня до workshop. Все читают. На workshop приходим с базой. Это удваивает выход.

Онлайн, гибрид, асинхронный варианты

Не у всех есть стена 6 метров и команда в одном офисе. Современные форматы работают, с поправками.

Полностью онлайн

Инструмент: Miro / Mural / Lucidspark (у всех есть Event Storming template). Я предпочитаю Miro — у них самый отзывчивый канвас и удобные шорткаты.

Камеры всех включены — это критично. Без камер потеряете ощущение совместной работы и parallelism.

Размер группы — максимум 8-10 человек. Больше — превращается в зум-вебинар, эффект ES теряется.

Каждый шаг — короче на 20-30%. Онлайн быстрее устают. 20-минутный Chaotic Exploration вместо 30 минут.

Запись доски — снимаем экран после каждого шага. В Miro есть встроенная история, но снимок с пометкой шага — надёжнее.

Гибрид (часть в офисе, часть удалённо)

Худший вариант. Те, кто в офисе у стены, видят больше; те, кто на видео, выпадают. Один человек в офисе с ноутбуком, который снимает доску для удалённых, не работает — фокус и резкость теряются.

Лечение: либо все в офисе, либо все онлайн. Если очень нужен гибрид — поставьте в офисе большой экран, на котором отображается Miro-доска, и пусть все работают только в Miro, даже офисные.

Асинхронный

Подходит для расширения / валидации, не для основного workshop. Используется так:

Делаем синхронный Big Picture (3 часа).
Раскидываем доску на 2-3 дня в Miro для async-уточнений: «Кто-то ещё видит события, которые мы пропустили? Клейте оранжевые в зону Async».
Через 3 дня делаем синхронный Walk Through по обновлённой доске (1 час).

Async только для дополнения. Сам Event Storming — синхронный по своей природе, потому что коллективный insight в нём важнее, чем индивидуальный вклад.

Чек-лист facilitator-а

Перед workshop:

[ ] Бизнес-описание проекта на 1-3 страницы — раздать за 2-3 дня
[ ] Глоссарий ключевых терминов — проверить, что все читали
[ ] Список участников, проверить роли (см. таблицу выше). Не зовём лишних.
[ ] Стена / Miro-доска готова, цвета стикеров согласованы
[ ] Тайм-боксы расписаны и распечатаны
[ ] Камера для съёмки доски (офлайн) или запись Miro (онлайн)

В начале:

[ ] Объяснить цель workshop за 5 минут
[ ] Объявить правила: события — прошедшее время, страдательный залог; на Шаге 1 не разговариваем; время на каждый шаг
[ ] Раздать маркеры / показать как работают цвета в Miro
[ ] Распределить большие розовые стикеры (External systems) и сиреневые (Policies) заранее в стороне

Во время:

[ ] Молчать на Шаге 1. Не помогать, не подсказывать, не комментировать
[ ] Жёстко держать тайм-боксы. Таймер на стене.
[ ] Поощрять конфликт между БА и архитектором — это ваш Hot Spot
[ ] Snimaть фото / делать снимок доски после каждого шага
[ ] Walk Through вслух обязательно

В конце:

[ ] Все Hot Spots проговорены, у каждого есть owner или решение
[ ] Bounded Contexts обведены и подписаны владельцами
[ ] Pivotal events отмечены жирной чертой
[ ] Назначен следующий шаг: когда делаем Process Level, по каким контекстам, кто участвует

После workshop:

[ ] Оцифровать доску в Miro в течение 24 часов (горячо)
[ ] Раздать результаты участникам в течение 48 часов
[ ] Открыть Hot Spots в трекере с owner-ом и сроком
[ ] Назначить дату Process Level workshop по приоритетным контекстам

Что дальше

Event Storming — это первый из четырёх артефактов нашей методологии. После него:

Данные с workshop переносятся в DDD-спеку по 16 разделам по приведённой выше таблице маппинга.
Спека пишется по гайдам для соответствующих ролей — БА, архитектор, разработчик.
На основе спеки скилл ucp-spec-design генерирует начальную раскладку UseCase-сервиса.
На основе UseCase-раскладки скилл ucp-pattern-design даёт каркас кода.

Полный пример этого пайплайна — в сквозном кейсе маркетплейса, где из Event Storming-а маркетплейса получается Tier C спека Order Service.

Если вы делаете Event Storming впервые — начните с маленького проекта или одного контекста. Полный workshop на маркетплейс с тремя уровнями — это 12-15 часов чистого workshop-времени плюс столько же на оцифровку и спеку. Не пытайтесь сделать всё за один день. Делайте Big Picture, потом перерыв на 1-2 дня, потом Process Level.

И главное: не бойтесь, что workshop пройдёт «не идеально». Любой Event Storming, даже неровный, даёт в десять раз больше данных, чем три недели интервью. Хороший facilitator появляется после трёх-пяти проведённых workshop, не раньше. Первый — будет неровным, и это нормально.

Гайд для БА