Event Storming

Event Storming — техника коллективного моделирования бизнес-процессов, основана на событиях

Метод помогает за короткое время выявить ключевые процессы, связи и точки интеграции без сложных нотаций BPMN или UML.
Строится вокруг событий, которые отражают значимые изменения состояния системы. Например, «Заказ создан», «Платёж подтверждён», «Товар доставлен».

Цели:

Понять, что происходит в системе и почему, визуально зафиксировав все важные события и связи между ними
Чтобы разработчики, аналитики, эксперты и менеджеры под одними и теми же словами понимали одно и то же.
Увидеть все "узкие места", противоречия и пробелы бизнес-процесса.
Создать основу для проектирования архитектуры

Примеры применения

запуск новой системы;
проектирование микросервисной архитектуры;
анализ существующего (legacy) решения перед рефакторингом;
уточнение сложных или неявных процессов между подразделениями.

Основные принципы

Фокус на событиях, а не на действиях или ролях.
Совместная работа: участвуют бизнес, аналитики, архитекторы и разработчики.
Минимум формализма: главное — содержание, а не визуальная строгость.
Динамика: быстро фиксировать идеи, не вдаваясь в детали на раннем этапе.
Причинно-следственные связи: каждое событие должно иметь причину и следствие.

Типы Event Storming-сессий

Big Picture

Используется для получения общего представления о домене.
Позволяет увидеть ключевые процессы и зависимости между ними.

Пример: визуализация полной цепочки «Заказ → Оплата → Доставка → Возврат».

Process Level

Детализирует конкретный бизнес-процесс.
Помогает определить события, команды и участников внутри него.

Пример: разбор процесса «Возврат товара» — от запроса покупателя до перевода средств.

Design Level

Уточняет модель до уровня архитектуры и bounded contexts.
Используется при проектировании микросервисов и взаимодействий между ними.

В DDD большая система декомпозируется на ограниченные контексты (bounded contexts).
Bounded Context — четко определённая граница в DDD, внутри которой термины и правила имеют единый смысл, а взаимодействие с другими частями системы происходит через явные интерфейсы.

Пример: разбиение домена e-commerce на контексты — «Заказы», «Платежи», «Доставка», «Уведомления».

Ключевые "строительные блоки"

Используются разноцветные стикеры под каждый вид.

Domain Event (Событие предметной области): Главный элемент. Факт, который уже произошел в системе. Всегда используется прошедшее время.
- Пример: Заказ размещён, Платёж подтверждён, Товар отправлен клиенту.
Command (Команда): Действие, которое инициирует выполнение операции и приводит к событию. Часто является реакцией на предыдущее событие.
- Пример: Разместить заказ, Подтвердить платёж, Отправить товар.
Actor (Актор): Пользователь или внешняя система, которая вызывает команду.
- Пример: Покупатель, Оператор кол-центра, Платёжный шлюз.
Aggregate (Агрегат): Ключевое понятие из DDD. Это "кластер" из связанных сущностей (например, Заказ с его позициями), который обрабатывает команды и порождает события. Агрегат — это граница согласованности данных.
Policy (Политика / Бизнес-правило): Автоматическая реакция на событие. Формулируется как "Когда [Событие X], тогда [Команда Y]".
- Пример: Когда "Платёж подтверждён", тогда "Отправить товар".
Read Model (Модель чтения): Данные, которые видит пользователь, чтобы принять решение и выполнить команду.
- Пример: Страница со списком товаров в корзине.

Пример как проходит Event Storming

Определить границы процесса.
Пример: «От момента оформления заказа до его доставки».
Зафиксировать доменные события в прошедшем времени:
«Заказ создан», «Платёж подтверждён», «Уведомление отправлено».
Добавить команды, которые инициируют события:
«Создать заказ», «Подтвердить платёж».
Указать акторов.
Кто выполняет действие — пользователь, система, внешний сервис.
Добавить агрегаты и сущности.
Они изменяют состояние при выполнении команд.
Зафиксировать политики и правила. «После подтверждения платежа — отправить заказ».
Сгруппировать события по смыслу.
Формируются bounded contexts — логические границы между частями системы.
Проверяются связи, исключения, альтернативные сценарии.
Результат: карта событий, отражающая процессы и зависимости.

Пример схемы доски Event Storming

+-------------------------------------------------------------+
|                       Event Storming                        |
+-------------------------------------------------------------+

[Актор]         [Команда]             [Событие]          [Сущность]
Покупатель ---> Размещает заказ ---> Заказ создан ---> Система заказов
                     │                     │
                     ▼                     ▼
              Подтверждает оплату ---> Платёж подтверждён ---> Платёжный сервис
                     │
                     ▼
                Заказ отправлен ---> Уведомление доставлено ---> Сервис уведомлений

Группировка по контекстам:

Контекст заказов
платежей
уведомлений

Каждый контекст можно выделить в отдельный микросервис.

Подготовка к сессии

Пример участников

бизнес-заказчик / product owner;
системные аналитики;
архитекторы;
разработчики.

Инструменты:

онлайн-доски:
- Miro
- Pruffme
- Holst, бесплатно
- Unidraw, бесплатно
- МТС Линк Доски
- FigJam
- Jamboard, бесплатно
- Эсборд
- Flip
- Microboard
- Boardmix
- Mural
- Яндекс Концепт
или доска, цветные стикеры, маркеры и таймер.

Правила:

Один модератор управляет темпом.
Все участники вносят события без обсуждения деталей.
После сбора проводится обсуждение, группировка и уточнение.

Артефакты и результаты

После сессии остаются:

Event Map — визуальная карта всех событий.
Bounded Contexts — определённые области ответственности.
Команды, акторы и политики — основа будущей архитектуры.
Понимание точек интеграции и последовательности действий.
Единое понимание предметной областиу всех участников.

Связь с DDD и микросервисами

Event Storming тесно связан с Domain-Driven Design (DDD).
DDD определяет подход к проектированию модели домена, а Event Storming помогает эту модель выявить.

Как работает:

События → контексты.
События группируются по смыслу и становятся границами bounded contexts.
Контексты → доменные модели.
В каждом контексте определяются свои сущности, агрегаты и команды.
Доменные модели → микросервисы.
Границы bounded contexts превращаются в границы сервисов.

Пример:

событие «Платёж подтверждён» — контекст «Платежи»;
событие «Заказ отправлен» — контекст «Логистика»;
между ними нет прямых зависимостей — значит, разные микросервисы.

Event Storming помогает избежать ошибок при разбиении монолита и определении интеграционных интерфейсов.

Плюсы и минусы

Быстрое формирование общего понимания предметной области.
Минимальные требования к подготовке.
Легко визуализировать и высокая вовлечённость участников.
Сочетается с DDD и микросервисным подходом.
Можно выявить скрытые зависимости и проблемные зоны.

Требует активного участия бизнеса и модерации.
При отсутствии дисциплины может превратиться в хаос.
Не даёт детальной модели сразу — требует доработки после сессии.
Сложно провести результативно без опыта

Event Storming

Примеры применения

Основные принципы

Типы Event Storming-сессий

Big Picture

Process Level

Design Level

Ключевые "строительные блоки"

Пример как проходит Event Storming

Пример схемы доски Event Storming

Подготовка к сессии

Артефакты и результаты

Связь с DDD и микросервисами

Плюсы и минусы

Материалы

Видео

Конференции

Книги

Примеры применения​

Основные принципы​

Типы Event Storming-сессий​

Big Picture​

Process Level​

Design Level​

Ключевые "строительные блоки"​

Пример как проходит Event Storming​

Пример схемы доски Event Storming​

Подготовка к сессии​

Артефакты и результаты​

Связь с DDD и микросервисами​

Плюсы и минусы​

Материалы​

Видео​

Конференции​

Книги​

Примеры применения

Основные принципы

Типы Event Storming-сессий

Big Picture

Process Level

Design Level

Ключевые "строительные блоки"

Пример как проходит Event Storming

Пример схемы доски Event Storming

Подготовка к сессии

Артефакты и результаты

Связь с DDD и микросервисами

Плюсы и минусы

Материалы

Видео

Конференции

Книги