Event Storming: 4 часа, которые стоят квартала разработки

TL;DR: Event Storming за одну сессию вскрывает то, что команда месяцами не замечает: скрытые процессы, мёртвые зоны между отделами, слова-обманки. Это не теоретическое упражнение, а конкретный инструмент, который окупается в первый же спринт. Ниже – пошаговый гайд: как подготовить, провести и превратить стикеры на стене в архитектурные решения.

---

В EdTech-платформе на проекте Andrews, о котором я рассказывал в первой статье, – мы готовились к ES-сессии с настроением “ну давайте попробуем, хуже не будет”. Система, которую один разработчик строил 2.5 года. CRM, платежи, воронки, рассылки, отчёты – всё в одном монолите, с god-таблицами и нулём документации.

Перед сессией я попросил каждого участника записать: “Как устроен процесс от первого касания клиента до оплаты курса?” Собрал пять ответов – продажи, методология, поддержка, бухгалтерия, разработка. Пять разных процессов. Не пять взглядов на один процесс, а буквально пять несовместимых картин мира.

Четыре часа. Ватман на стене, оранжевые стикеры, маркеры, люди из разных отделов в одной комнате.

Что обнаружилось – я частично рассказывал в предыдущей статье: мёртвые зоны между отделами, круговой процесс возврата, “студент” как четыре несовместимых сущности в одной таблице. Но на самой сессии ключевым был не перечень находок, а момент, когда это произошло.

На сороковой минуте продажник приклеил стикер “Лид передан менеджеру”, а методолог рядом – “Автоматическая рассылка отправлена”. Они посмотрели друг на друга. “Подожди, вы тоже ему пишете?” Два года работы в одной компании – и они впервые узнали, что обрабатывают одного и того же человека параллельно, с разными офферами. Этот момент стоил всей сессии.

Ещё обнаружились три бизнес-правила, о которых знал только один человек. Который уволился два месяца назад.

До сессии мы были уверены, что понимаем систему. После – поняли, что не понимаем даже терминологию.

В предыдущей статье мы разбирали, почему предположения – главный враг проекта. Event Storming – первый конкретный инструмент, который эти предположения вытаскивает на поверхность. Не через код, не через документацию, а через разговор нужных людей в одной комнате.

Зачем Event Storming – и кому именно

Event Storming придумал Альберто Брандолини. Идея простая: собрать людей, которые знают разные куски домена, и попросить их рассказать, что происходит в системе – через события, записанные на стикерах. Не UML-диаграммы, не user stories – а факты: “что произошло”.

Но “зачем это мне?” – вопрос, который задаёт каждая роль по-своему.

Разработчик получает понимание домена за часы, а не за месяцы чтения кода и расспросов коллег. Вместо археологии по legacy-коду – живая карта процессов. После одной сессии на проекте Andrews я за день разобрался в процессах, которые до этого восстанавливал по коду две недели.

Product Owner / аналитик видит полную картину, а не свой фрагмент. Помнишь тех аналитиков из языковой школы, которые писали обоснования невозможности фич? Они описывали то, что видели. ES показывает то, что между видимым.

Доменный эксперт наконец получает площадку, где его знания востребованы. Не формат “расскажите нам всё” (невозможно) и не “ответьте на 50 вопросов” (бессмысленно). А совместное моделирование, где знания проявляются органично – через конфликты, уточнения, вопросы.

Архитектор получает карту, из которой проявляются границы контекстов. Не из головы, не из диаграмм на доске, а из реальных бизнес-процессов. Bounded contexts вырисовываются сами – через кластеры событий и точки, где язык меняется.

Брандолини однажды заметил, что в типичном проекте разработчики пишут код на основе предположений – и в этом проблема. ES заставляет столкнуть эти предположения до того, как они попадут в кодовую базу.

Подготовка: 80% успеха – до первого стикера

Кого звать

Правило: нужны люди, которые знают “что” и люди, которые знают “как”. Продакт + доменный эксперт + разработчик – минимальное ядро. Идеально – 6-10 человек.

На Andrews мы звали продажников, методологов, поддержку, бухгалтерию и двух разработчиков. Десять человек – на грани, но для CRM, покрывающей всё от маркетинга до зарплат, меньше было нельзя.

Кого не звать:

• Наблюдателей. Руководителя, который “просто послушает”. Человек, молча сидящий с ноутбуком, меняет комнату. Люди начинают фильтровать, играть на публику, а не думать. Если начальник хочет результаты – покажи ему итоговую карту после сессии или позови на последний час, когда картина уже проявилась.
• Слишком старших в иерархии. CEO на сессии с рядовыми сотрудниками – почти гарантированный провал. Даже если он искренне хочет “послушать”, продажник не скажет “у нас нет регламента на возврат” в присутствии человека, который должен был его утвердить три года назад. Люди скажут то, что безопасно сказать, а не то, что правда. У меня была сессия, где директор департамента сидел в углу – и два ключевых процесса всплыли только через неделю в кулуарной беседе.
• Тех, кто пришёл обсуждать реализацию. Разработчик, который в середине сессии начинает спорить про выбор базы или “давайте сразу на Kafka” – забирает энергию в сторону, где домен уже не обсуждается. Проговори с такими ребятами заранее: сегодня мы не обсуждаем технологии. Вообще. Ноль. Если не принимают – лучше не звать, чем переубеждать на сессии.
• Участников в открытом конфликте. Если продажи и методологи полгода воюют за KPI, ES станет ареной этой войны. Сессия превратится в перекидывание вины, а не в выяснение процесса. Сначала решаем конфликт – потом ES. Или разводим их по разным сессиям.
• Внешних консультантов, которых команда не знает. Человек со стороны фильтрует разговоры одним своим присутствием: люди начинают объяснять контекст вместо того, чтобы обсуждать процесс. Исключение – если консультант уже несколько недель в проекте, и его знают.

Если сомневаешься – лучше позови. Лишний доменный эксперт не повредит. А вот лишний руководитель или философ-архитектор – ещё как.

Как продать идею

Сопротивление гарантировано. Разработчики: “Четыре часа на стикеры? Я за это время фичу напишу”. Менеджеры: “У нас нет четырёх часов, у нас дедлайн”. Доменные эксперты: “Зачем мне это? Я и так всё знаю”.

Что работает:

• Разработчикам: “Помнишь, как две недели разбирался, почему платежи ломают отчёты? За 4 часа мы бы это увидели на стене, а не в проде.”
• Менеджерам: “Мы тратим 60% времени на хотфиксы. Одна сессия покажет, почему, и сэкономит месяцы.”
• Экспертам: “Ваши знания – самое ценное, что есть у проекта. Сейчас они в вашей голове. Если вы завтра уйдёте в отпуск, проект встанет. ES – способ это изменить.”

Не продавай ES как “методологию”. Продавай как “давайте за 4 часа разберёмся, что мы на самом деле строим”. (Про собственные провалы продажи подробнее рассказывал в Telegram.)

Что подготовить

• Пространство. Длинная стена – минимум 5-6 метров. Или несколько флипчартов в ряд. Стикеры не помещаются на доске для совещаний – это первая ошибка, которую совершают все.
• Стикеры. Много. Четыре цвета минимум: оранжевые (события), синие (команды), жёлтые (агрегаты), фиолетовые (hot spots / вопросы). Плюс зелёные – я использую их для определений и уточнений терминов (в каноничном ES зелёные часто идут на read models, но на первых сессиях определения важнее). Закупай с запасом – на сессию из 8 человек уходит 200-300 стикеров.
• Маркеры. Толстые, чтобы текст читался с расстояния. Тонкие ручки – враг ES: через час никто не может прочитать чужие стикеры.
• Тайминг. 4 часа – стандарт. Можно 3, если домен небольшой. Можно 6, если домен огромный. Нельзя “часик” – не успеете выйти из хаоса.

Роль фасилитатора

Ты не ведущий и не эксперт. Ты задаёшь вопросы и следишь за процессом. Звучит просто – а на практике это 4 часа постоянной работы, где ты всё время решаешь, вмешаться или подождать.

Открытие сессии. Первые 10 минут задают тон. Не начинай с теории – “Event Storming был придуман в 2013 году Альберто Брандолини…” гарантированно обнуляет энергию. Начинай с проблемы: “У нас есть система. Мы не уверены, что одинаково её понимаем. Сейчас проверим. На стене сегодня появится карта того, что реально происходит – со всеми пробелами и противоречиями. Не старайтесь делать красиво. Старайтесь делать честно.” Потом – правила стикеров (события в прошедшем времени), потом – молча клеим первый оранжевый стикер и начинаем.

Когда комната молчит. Первые 5-10 минут тишины – нормально. Люди не знают, с чего начать. Не спасай их объяснениями. Вместо этого – приклей сам один очевидный стикер (“Пользователь зарегистрирован” или что-то столь же базовое) и скажи: “Что происходит дальше? Или до этого?” Один стикер на стене ломает парализующую пустоту лучше, чем десять минут объяснений.

Когда говорит один, молчат остальные. В каждой команде есть доминантный человек, обычно самый уверенный или самый громкий. Через полчаса он начнёт объяснять “как оно работает на самом деле”. Остальные соглашаются или молчат. Это ловушка – ты получишь его картину мира, а не команды. Что работает: физически перемести его к стене и скажи: “Напиши это на стикере”. Пока он пишет – обратись к молчащему: “А ты согласен? У тебя в отделе так же устроено?” Как только молчуны понимают, что их мнение важно, баланс восстанавливается.

Когда спор заходит в тупик. Два человека 10 минут спорят, как устроен процесс возврата. Ни один не уступает. Не пытайся их помирить – клеишь фиолетовый hot spot: “Процесс возврата – две версии”. Пишешь обе. Идёшь дальше. Решение – не здесь и не сейчас. Твоя задача – зафиксировать разногласие, а не решить его.

Когда тянет моделировать самому. Самая сильная ловушка. Ты видишь пропущенное событие и хочешь подсказать: “А тут, наверное, должно быть Оплата подтверждена?” Не подсказывай. Задавай вопрос: “Что должно произойти, чтобы клиент увидел свой билет?” Если команда не приходит к ответу – это ценная информация. Значит, процесс непонятен. Это hot spot, а не фасилитаторский просчёт.

Когда энергия падает. После двух часов все устают. Клеят стикеры медленнее, спорят вяло. Не игнорируй – перерыв, вода, короткая прогулка. Восемь минут отдыха дороже получаса вымученного моделирования. После перерыва смени формат: от хаотичного добавления событий переходи к обратному проходу – проигрывай процесс справа налево. Другой режим мышления возвращает включённость.

И базовое: задавай вопросы, а не давай ответы. “А что происходит после оплаты?” – правильно. “После оплаты нужно отправить уведомление” – неправильно, даже если ты знаешь, что так и есть. Знания должны прийти от команды. То, что ты достал из своей головы – не работает, потому что остальные не поверят, что это их знания.

Итерация 1: Хаос → Структура

Первая итерация – про события. Только события. Ничего больше.

Оранжевые стикеры: что произошло?

Правило формулировки: прошедшее время, свершившийся факт.

Правильно	Неправильно
Бронирование создано	Создать бронирование
Оплата подтверждена	Обработка платежа
Поездка отменена	Отмена поездки
Согласование получено	Процесс согласования

Событие – это то, что уже случилось. Не процесс, не действие, не функция. Факт. “Товар добавлен в корзину”, а не “Добавление товара”. Разница кажется косметической, но она принципиальна: событие заставляет думать о результатах, а не о процедурах.

Фаза хаоса (30-40 минут)

“Напишите всё, что происходит в системе. Каждое событие – отдельный стикер. Не думайте о порядке. Не обсуждайте. Просто пишите и клейте на стену.”

Первые 5 минут – тишина и растерянность. Нормально. Потом кто-то клеит первый стикер – и начинается.

На Andrews за 30 минут стена покрылась сотней оранжевых стикеров. Хаос. Дубликаты, противоречия, стикеры в случайном порядке. “Студент зарегистрирован” рядом с “Платёж получен” рядом с “Курс завершён”. Выглядит как бардак. Так и задумано.

На этом этапе фасилитатор не вмешивается в содержание. Дубликаты? Ок. Противоречия? Ещё лучше – значит, люди видят процесс по-разному. Ради этого и затевали.

Группировка и временная ось (30-40 минут)

“Теперь давайте выстроим это в порядке, как оно происходит. Слева – начало, справа – конец.”

Команда начинает двигать стикеры. И тут начинается самое интересное – споры.

“Подождите, согласование идёт ДО бронирования!” – “Нет, у нас сначала бронируют, потом согласовывают!” – “А у корпоративных клиентов вообще другой процесс!”

Каждый такой спор – обнаруженное предположение. Если бы эти люди не стояли у одной стены, расхождение проявилось бы через три месяца, в продакшене, в виде бага.

На этом этапе убираются дубликаты, объединяются синонимы, выстраивается временная линия. Но не идеальная – пробелы и вопросы остаются.

Фиолетовые стикеры: Hot Spots и вопросы

Когда возникает спор, который не решается за минуту, или обнаруживается “а этого мы не знаем” – клеим фиолетовый стикер. Это hot spot: место, где живёт неопределённость.

На Andrews hot spots были:

• “Кто отвечает за возврат?” (никто)
• “Что происходит, если студент оплатил, но не начал курс в течение 30 дней?” (никто не знал)
• “Как работает продление подписки?” (три версии от трёх отделов)

Hot spots – самый ценный артефакт первой итерации. Каждый фиолетовый стикер – предположение, которое могло бы стать багом.

Зелёные стикеры: определения

Когда выясняется, что слово значит разное для разных людей – клеим зелёный стикер с определением. “Студент (для продаж) = лид, потенциальный покупатель”. “Студент (для методологии) = человек, проходящий курс”.

На Andrews зелёных стикеров набралось 3 десятка. Каждый – развилка, где Ubiquitous Language ломался. Каждый – потенциальный god object в коде.

Обратный проход: проигрываем справа налево

После выстраивания временной оси – проходим в обратном направлении. Берём последнее событие и спрашиваем: “А что должно произойти, чтобы это случилось?”

Этот приём вскрывает пропущенные шаги. На Andrews обратный проход обнаружил, что между “Курс оплачен” и “Студент получил доступ” есть невидимый этап: ручная активация менеджером. В коде это был if-блок в контроллере, о котором знал один человек. На стене он стал видимым – и стало очевидно, что это кандидат на автоматизацию.

К концу первой итерации на стене – временная линия событий с hot spots и определениями. Хаос превратился в структуру. Но это ещё не архитектура – это карта того, что происходит. Вторая итерация покажет, почему это происходит.

Итерация 2: Кто, что и почему

Если первая итерация отвечает на “что происходит?”, вторая – на “кто инициирует?”, “что принимает решение?” и “какие правила действуют?”.

Синие стикеры: команды

Команда (Command) – действие, которое кто-то совершает и которое может быть отклонено.

Событие (оранжевый)	Команда (синий)
Бронирование создано	Создать бронирование
Поездка отменена	Отменить поездку
Согласование получено	Согласовать поездку

Ключевое отличие: событие – факт, оно уже произошло. Команда – намерение, она может не пройти. “Отменить поездку” может быть отклонено, если политика не позволяет отмену за 24 часа до вылета. Это различие заставляет команду думать о валидации, ограничениях, бизнес-правилах.

Жёлтые стикеры: агрегаты

Между командой и событием стоит агрегат – то, что принимает решение. Кластер данных и правил, который гарантирует корректность.

Это первое знакомство с агрегатами, и на ES-сессии не нужно глубокое понимание. Достаточно простого вопроса: “Кто решает, можно ли это сделать?”

“Создать бронирование” → Бронирование решает, корректен ли запрос → “Бронирование создано”

“Согласовать поездку” → Политика поездки проверяет соответствие правилам → “Согласование получено” (или “Согласование отклонено”)

Агрегаты на ES – это жёлтые стикеры, наклеенные поверх кластера команд и событий. Они группируют связанное поведение. Мы вернёмся к ним подробно в статье про тактические паттерны DDD.

Политики и бизнес-правила

Иногда событие порождает другое действие автоматически. “Бронирование отменено” → автоматически → “Инициировать возврат”. Это политика – бизнес-правило, которое связывает события и команды.

Политики – одно из самых ценных открытий ES. На Andrews мы обнаружили политику, о которой знал только уволившийся разработчик: если клиент не начал курс в течение 14 дней после оплаты, система автоматически отправляла напоминание – но только VIP-клиентам. Для остальных – тишина. Почему? Никто не знал. В коде это был захардкоженный if с комментарием ”// временно”. Два года.

Read Models: что видит пользователь

Read Model – представление данных, которое помогает пользователю принять решение. На стене это стикер рядом с командой: перед тем как “Согласовать поездку”, согласующий видит Read Model: бюджет отдела, лимиты по классу обслуживания, историю поездок сотрудника.

Read Models важны, потому что показывают: для принятия решения нужна информация из нескольких контекстов. Это подсказка архитектору, что здесь, возможно, потребуется проекция или API-вызов между контекстами.

Картинка, которая объясняет всё

К концу второй итерации на стене вырисовывается паттерн:

Пользователь (Actor) отправляет команду (Command). Агрегат (Aggregate) решает, допустима ли она, и порождает событие (Event). Событие обновляет Read Model или запускает политику (Policy), которая порождает следующую команду.

Это не теоретическая схема – это буквально то, что видно на стене после двух итераций. Каждый стикер на своём месте. Каждая связь – результат обсуждения реальных людей, которые знают домен.

Полный пример: Business Travel

Давай пройдём ES-сессию на домене бронирования деловых поездок – я работал в этой области до Andrews, на проекте корпоративного тревел-менеджмента. Реконструирую сессию по реальному опыту, анонимизировав детали.

Итерация 1: события

Команда клеит стикеры. Через 30 минут на стене:

Happy path: Командировка запрошена → Политика проверена → Согласование запрошено → Согласование получено → Бронирование создано → Сегмент добавлен → Оплата инициирована → Оплата подтверждена → Билет выписан.

Альтернативные ветки:

• Согласование отклонено → Командировка отменена.
• Командировка отменена → Возврат рассчитан → Возврат выполнен.

Hot spots (фиолетовые):

• “А что если политика изменилась между запросом и согласованием?” – никто не знает.
• “Частичная отмена – один сегмент из трёх. Как?” – два противоречивых ответа.
• “Кто видит статус согласования? Только инициатор или и его руководитель и тревел-менеджер тоже?” – зависит от компании.
• “Что происходит, если оплата прошла, а билет не выписался?” – “ну, тикет в поддержку…”

Зелёные стикеры:

• “Бронирование” для тревел-менеджера = заявка на согласование. Для путешественника = подтверждённый маршрут. Для бухгалтерии = строка расхода. Три разных сущности под одним словом.
• “Сегмент” = один элемент маршрута: перелёт, отель, ЖД-билет. Не “этап поездки”.

Итерация 2: команды, агрегаты, политики

Что становится видно:

• Четыре кластера вокруг разных агрегатов: Командировка, Политика, Бронирование, Платёж. Четыре потенциальных bounded contexts.
• Политика автосогласования – бизнес-правило, которое не было в ТЗ. Тревел-менеджер не хочет согласовывать каждый эконом-билет за 3000 рублей. Есть порог – ниже которого согласование автоматическое. Это обнаружилось, потому что тревел-менеджер стоял у стены и сказал: “Подождите, я же не каждый раз это делаю”.
• Read Model перед согласованием – подсказка, что согласующему нужна информация из бюджетного контекста.
• Разрыв между “Оплата подтверждена” и “Билет выписан” – это не мгновенный переход, а асинхронный процесс с возможным сбоем. Hot spot, который станет сагой в коде.

От стикеров к Bounded Contexts

ES не даёт готовую архитектуру. Он даёт карту, из которой архитектура проявляется.

Никто не рисует bounded contexts заранее. Они проявляются из карты – если знаешь, куда смотреть.

Языковые границы – самый надёжный сигнал. Там, где меняется значение слова, проходит граница контекста. “Бронирование” для Booking BC = набор сегментов с маршрутом и статусом. Для Payment BC = сумма к оплате с валютой и invoice line items. Для Trip Policy BC = запрос, который нужно проверить по правилам. Одно слово, три модели – три контекста.

Кластеры событий. На нашей стене видно четыре группы: вокруг Командировки (запрос, согласование), вокруг Бронирования (создание, сегменты), вокруг Платежа (оплата, возврат), вокруг Политики (проверка правил, лимиты). Каждая группа – кандидат в bounded context.

Точки асинхронности. Где между событием и следующей командой – задержка, ожидание, возможный сбой – скорее всего, граница. “Бронирование создано” → … → “Оплата инициирована” – этот переход не мгновенный, здесь два контекста интегрируются.

И ещё один маркер – разные владельцы. На Andrews продажи владели воронкой, методологи – курсами, бухгалтерия – платежами. Три команды, три потенциальных контекста. Закон Конвея в действии.

Результат ES на business-travel домене:

Эта карта – не финальная архитектура. Это гипотеза, которую нужно проверить. Но гипотеза, основанная на знаниях десяти человек, а не на предположениях одного архитектора. И уж точно не на том, что сгенерировал AI-ассистент по вашему промпту “спроектируй микросервисы для travel-системы”. AI-агент не знает, что в вашей компании согласование проходит через тревел-менеджера, а не через систему. Люди у стены – знают.

Ошибки фасилитатора: что я делал не так

Ошибка 1: Не пригласил скептика

Звал тех, кто и так “за ES”. Получалась тёплая компания, которая кивала на каждое событие. Красиво, быстро, бесполезно – никто не задавал неудобных вопросов. С тех пор всегда зову хотя бы одного скептика. Того, кто спросит “а точно это работает именно так?” и не побоится возразить старшему. Без такого человека ES превращается в коллективное самоубеждение.

Ошибка 2: Слишком ранняя структуризация

На одной сессии я начал двигать стикеры в хронологический порядок через 15 минут. Рано. Хаос должен накопиться – люди ещё не выгрузили всё, что знают. Торопишь структуризацию – получаешь неполную картину. Потерпи 30-40 минут хаоса.

Ошибка 3: Не пригласил нужных людей

Проводил ES без поддержки. Получил красивую карту happy path. Все edge cases, возвраты, ошибки, ручные обходные пути – прошли мимо, потому что о них знали те, кого не позвали. Поддержка знает о системе то, чего не знает даже разработчик, который её написал.

Ошибка 4: Не зафиксировал результат

После первой сессии я сфотографировал стену и решил, что этого достаточно. Через неделю фотографии стали нечитаемыми – стикеры мелкие, текст размытый, контекст потерян. Теперь после каждой сессии я трачу час на оцифровку: перенести в Miro, подписать, сохранить hot spots отдельным списком. Скучно, но без этого результат испаряется.

Ошибка 5: Затянул сессию

Шесть часов. Без достаточных перерывов. К пятому часу люди клеили стикеры механически, обсуждения заглохли, энергия ушла. Четыре часа – оптимум. Если нужно больше – лучше две сессии по 3-4 часа с перерывом в день, чем один марафон.

Remote ES: когда нет другого выхода

Иногда собрать всех в одну комнату невозможно. Miro и FigJam – компромисс. Рабочий, но компромисс.

Что теряешь:

• Тактильность. Физический стикер ты берёшь, пишешь, клеишь – тело участвует в процессе. В Miro всё – через мышку, и это снижает вовлечённость.
• Энергию комнаты. Когда десять человек стоят у стены, споря о том, что происходит после оплаты – это другой уровень включённости, чем десять окон в Zoom.
• Невербалику. Видно, когда человек у стены хмурится, глядя на чужой стикер. В Zoom – не видно.
• Периферийное зрение. У физической стены ты видишь всю картину целиком. В Miro – только то, что влезает в экран.

Что помогает:

• Подготовленный шаблон. В Miro заранее создай зоны: временная ось, область для hot spots, область для определений. Без шаблона люди теряются – в физическом пространстве стена сама задаёт структуру, в цифровом – нет.
• Строгий тайминг с таймером на экране. Без визуального таймера remote-сессии расплываются. 30 минут на хаос, 5 минут перерыв, 30 минут на структуризацию.
• Камеры включены, обязательно. Без камер ты фасилитируешь в пустоту.
• Меньше участников. 6-8 – максимум для remote. Больше – и часть людей отключается ментально (физически они ещё в Zoom, но уже проверяют почту).
• Голосовое сопровождение. В офлайне люди комментируют стикеры, пока клеят. В Miro – молча двигают прямоугольники. Попроси каждого озвучивать, что он добавляет: “Я добавил событие Бронирование отменено, потому что…”

Remote ES лучше, чем никакого ES. Но если есть шанс собрать людей вживую хотя бы на первую сессию – собирай. Разницу почувствуешь в первые полчаса.

Реальный расклад четырёхчасовой сессии

Время	Что	Цель
0:00-0:15	Введение	Объяснить формат, правила стикеров, роли
0:15-0:50	Хаос	Все пишут события, клеят на стену
0:50-1:00	Перерыв
1:00-1:40	Группировка	Временная ось, дедупликация, споры
1:40-2:00	Hot spots	Фиксируем вопросы и расхождения
2:00-2:15	Перерыв
2:15-2:50	Команды и агрегаты	Синие и жёлтые стикеры
2:50-3:20	Политики и read models	Связи между событиями
3:20-3:30	Перерыв
3:30-3:50	Обзор карты	Обратный проход, поиск пробелов
3:50-4:00	Итоги	Hot spots → action items, next steps

Тайминги ориентировочные – на практике фаза хаоса затягивается почти всегда, а на команды и агрегаты может не хватить времени. Это нормально. Первая итерация (события + hot spots) – обязательный минимум. Вторую можно провести отдельной сессией через пару дней, когда участники переварят увиденное.

Что дальше

Когда ES – overkill

CRUD-приложение на два экрана, один разработчик, который сам же и доменный эксперт – тут ES не нужен. Ты и так знаешь всё, что нужно знать. Инвестиция окупается там, где знания фрагментированы между людьми, а домен сложнее, чем может удержать одна голова. Если в твоей команде больше трёх человек и хотя бы один из них говорит “а, это к Васе, он знает” – тебе пора к стене со стикерами.

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

Что делать с результатами:

1. Hot spots – превратить в backlog items. Каждый фиолетовый стикер – задача на исследование или решение. Это самый ценный выход ES.
2. Кластеры событий – гипотезы о bounded contexts. Проверять их будем в следующей статье, когда разберём DDD как фреймворк для принятия решений.
3. Зелёные стикеры – начало Ubiquitous Language. Зафиксируй их и используй в коде. Буквально: если на стене написано “Сегмент”, в коде должен быть TripSegment, а не BookingItem.
4. Карта целиком – оцифруй и повесь в Confluence / Wiki / Miro. Она устареет через 3-6 месяцев – и тогда проведи ещё одну сессию. ES не разовое упражнение.

Мы уже знаем, что предположения – главный враг проекта. Теперь у нас есть карта. Осталось научиться по ней строить.

Следующая статья – “DDD: не серебряная пуля, а набор компромиссов”. Возьмём карту, которую построили здесь, и разберём: когда DDD оправдан, когда избыточен, и как не превратить внедрение в карго-культ. А жёлтые стикеры-агрегаты превратятся в код – в статье про тактические паттерны DDD.

Обсуждение – в Telegram-канале. Там короче, острее и чаще.

---

Что почитать по теме

• Introducing EventStorming – Alberto Brandolini. Книга автора техники (на Leanpub). Единственный первоисточник; всё остальное – пересказы.
• EventStorming.com – сайт Брандолини с описанием формата, FAQ и ссылками на доклады.
• Domain-Driven Design Distilled – Vaughn Vernon. Кратко затрагивает Event Storming как технику discovery – хорошая отправная точка, если хочется контекст DDD вокруг ES.
• Collaborative Software Design – Evelyn van Kelle, Gien Verschatse, Kenny Baas-Schwegler. Практические техники совместного моделирования, включая ES и его вариации.
• Visual Collaboration Tools – Kenny Baas-Schwegler, João Rosa и соавторы. Сборник визуальных техник за пределами ES: Domain Storytelling, Example Mapping, Context Mapping.