Источник
EventStorming (book_cube)
Практический разбор техники, шагов воркшопа и артефактов сессии.
Источник
EventStorming (book_cube)
Практический разбор техники, шагов воркшопа и артефактов сессии.
EventStorming это быстрый способ синхронизировать доменные знания между экспертами и инженерами. Вместо длинных спецификаций команда совместно строит карту событий, команд, политик и границ контекстов, а потом использует эту карту как основу для архитектурных решений.
TL;DR
- EventStorming быстро выравнивает доменный контекст между всеми ролями.
- Карта событий помогает увидеть реальные зависимости и критические решения.
- После сессии команда получает основу для DDD, архитектуры и roadmap внедрения.
Зачем использовать EventStorming
Синхронизация домена
Быстро выявляет расхождения в понимании между экспертами, продуктом и инженерией.
Явные зависимости
Показывает ключевые события, связи и точки автоматизации в реальном бизнес-потоке.
Основа архитектуры
Привязывает технические решения к событиям, а не к абстрактным гипотезам.
Переход к DDD
Создает материал для выделения aggregates и bounded contexts.
Пошаговый воркшоп
Текущий пункт
Нажмите «Старт», чтобы проиграть последовательность шагов EventStorming.
Пример потока для домена A/B экспериментов
- PM формулирует гипотезу эксперимента.
- Публикуется команда запуска эксперимента.
- Событие «эксперимент активирован» инициирует распределение трафика.
- События телеметрии поступают в аналитический контур.
- Policy по истечении окна эксперимента инициирует остановку.
- Событие «эксперимент завершен» запускает расчет метрик и отчет.
- Команда принимает решение: rollout, rollback или новая итерация.
Роль фасилитатора
Фасилитатор управляет не «правильностью ответов», а качеством общего мышления: следит за темпом, фиксирует конфликтующие трактовки и не дает уходить в преждевременные технические детали.
Полезные практики
- Начинать с общего happy path и только потом идти в исключения.
- Держать единый глоссарий терминов прямо на доске.
- Отдельно помечать спорные места и зоны неопределенности.
- Ограничивать deep-dive по времени, чтобы удерживать ритм сессии.
Типичные ошибки
- Сразу обсуждать сервисы и базы данных до прояснения событий.
- Смешивать роли actor, policy и system notifications.
- Строить одну «универсальную модель» без границ контекстов.
- Не фиксировать решения после воркшопа в рабочие артефакты.
Что должно остаться после сессии
- Согласованный timeline ключевых доменных событий.
- Карта command/policy/actor для основных потоков.
- Черновые границы агрегатов и bounded contexts.
- Список открытых вопросов и гипотез для следующей итерации.