Продолжаем сегодня говорить о серьёзном. Команды, которые создают прикладные информационные системы, часто расходятся в описании одного и того же бизнес-процесса. В обсуждении участвуют представители бизнеса, аналитики, разработчики, тестировщики и инженеры эксплуатации. У каждого есть часть картины, но целого описания нет: одни говорят о формах и полях, другие — о статусах и проверках, третьи — о нагрузке и сбоях. В результате требования противоречат друг другу, сроки растут, а реализованные функции не совпадают с ожиданиями. И здесь может помочь Event Storming. давайте разберемся, что это такое вместе.
Что такое Event Storming
Event Storming — совместное моделирование предметной области через цепочку доменных событий. Доменное событие — это факт, который уже произошел и имеет значение для бизнеса. Формулировка всегда в прошедшем времени. Примеры простые и прямые: заказ создан, платеж подтвержден, возврат оформлен. Работу над событиями дополняют два элемента. Команда — это запрос на изменение состояния, который отправляет человек или система. Политика — это автоматическое правило, которое срабатывает при наступлении события и инициирует дальнейшие действия. Этого набора достаточно, чтобы увидеть причинно-следственные связи и перейти к техническим решениям без догадок.
Зачем это нужно разработчикам и аналитикам
События дают опорную линию. Команды связывают бизнес намерения с интерфейсами и точками входа. Политики показывают, где лучше работать асинхронно и что именно должно происходить без участия пользователя.
На одной доске появляются ответы на базовые вопросы:
- Что было сделано
- Кто инициировал действие
- При каких условиях команда должна быть отклонена
- Какие данные обязательны
- Что должно запуститься автоматически после факта
Когда такие ответы записаны, архитектурные решения выходят естественно. Видно, какие обработчики нужны, где разделить сервисы, какие сообщения публиковать, какие проверки включить в тесты.
Короткий словарь без двусмысленностей
Команда в рамках Event Storming — это не коллектив людей. Это действие, поступающее в систему. Примеры формулировок в повелительном наклонении понятны каждому участнику: оформить заказ, принять оплату, отменить отгрузку.
Актор — инициатор команды. Это может быть пользователь, внешний сервис, расписание задач.
Агрегат — группа данных и правил целостности, которые изменяются вместе. Примером служит заказ со строками, суммой и статусом.
Граница контекста — часть модели, где термины и правила согласованы. На границах контекстов проходят **интеграции** с явными контрактами.
Эти определения достаточны для практической работы и совпадают с устоявшейся терминологией.
Мини-сценарий интернет-магазина
Начало процесса. Пользователь отправляет команду оформить заказ. Система проверяет, что корзина не пуста и клиент идентифицирован. Эти проверки — предусловия команды. Если они выполнены, система фиксирует событие заказ создан. Это факт, который можно журналировать и использовать далее. На событие срабатывает политика. Она резервирует товары и инициирует команду запросить оплату. Платежный шлюз обрабатывает запрос и отправляет уведомление. Магазин получает событие платеж подтвержден. В ответ запускается следующая политика. Заказ попадает в очередь на отгрузку, клиент получает письмо. Когда склад запаковал заказ и передал его в службу доставки, появляется событие посылка отгружена.
В этом коротком фрагменте видны намерения, факты, автоматические реакции и зоны ответственности. Появляются и технические выводы. Команда оформить заказ — это HTTP POST на точку входа. События платежа приходят вебхуком. Политики лучше реализовать асинхронно через очередь. Инварианты агрегата заказ просты и проверяемы. Нельзя подтверждать платеж для заказа в статусе отменен. Нельзя списывать оплату, если резерв не создан.
Как проходит сессия
Подготовка минимальна. Нужна широкая поверхность для временной линии и набор карточек. Сначала участники записывают события короткими фразами в прошедшем времени. На этом шаге не обсуждаются таблицы и форматы. Цель — собрать факты, важные для бизнеса. Затем события раскладываются по времени, похожие формулировки объединяются, спорные уточняются. После этого команда добавляет действия, которые могли привести к каждому факту. Здесь прямо указываются инициаторы и каналы. Пользователь и POST, расписание и фоновое задание, внешний сервис и вебхук. Следующий слой — политики. Для значимых событий фиксируются автоматические реакции. Они подскажут, где нужны подписчики очереди, а где достаточно транзакции в рамках одного сервиса.
Когда события, команды и политики связаны, видно, какие данные необходимы для выполнения действий, какие проверки обязательны и какие инварианты нельзя нарушать. На этом этапе удобно выделять агрегаты и границы контекстов. Там, где словарь и правила отличаются, проходит граница. Там же появляются явные контракты интеграции.
Что получается в результате
Event Storming создает пять ключевых артефактов:
- Лента событий и действий без разрывов — главное **артефакт**. Она превращается в схему интерфейсов и обработки сообщений.
- Список политик — перечень автоматических реакций, которые нужно реализовать.
- Набор инвариантов — конкретные правила целостности, которые попадут в тесты и проверки на уровне кода.
- Карта границ контекстов — помогает определить, где закончить ответственность одного сервиса и начать ответственность другого.
- Словарь терминов — исключает разночтения в требованиях и документации.
Переход к технике без лишних слоев
Команды напрямую становятся точками входа. Наименования и параметры берутся из формулировок на доске. Пример понятен. Команда оформить заказ соответствует методу POST на адресе orders. События становятся сообщениями, которые публикует сервис-источник и обрабатывает сервис-получатель. Платеж подтвержден удобно передавать через шину сообщений, чтобы склад и уведомления не зависели от внутреннего кода оплаты. Наблюдаемость опирается на те же названия. В журнал пишется имя события, идентификатор агрегата, источник и ключевые данные. Тесты строятся по шаблону команда предусловия ожидаемое событие. Такой тест воспроизводим и понятен вне контекста конкретной реализации.
# точка входа команды оформить заказ POST /orders { "items": [{"sku": "A-123", "qty": 2}], "customerId": "c-001", "delivery": {"type": "courier", "city": "Москва"} } # сообщение события платеж подтвержден { "event": "payment_confirmed", "orderId": "o-100500", "paymentId": "p-777", "amount": 3500, "currency": "RUB", "occurredAt": "2025-09-21T12:10:00Z" } Где чаще всего ошибаются
Четыре основные ошибки и их решения:
- Смешивать термины из разных контекстов
Решение: фиксировать словарь и отмечать границы. - Писать события техническим жаргоном
Решение: формулировать результат для бизнеса. - Обсуждать таблицы и коды до того, как согласованы факты и правила
Решение: держать порядок. Сначала события, затем действия и реакции, после этого интерфейсы и форматы. - Не указывать причину события
Решение: для каждого факта записывать команду или политику, которые к нему привели, и перечислять обязательные данные.
Ответы на вопросы, которые задают чаще всего
Что дает политика?
Политика фиксирует автоматическую реакцию на факт. Это не пользовательский сценарий и не ручная операция. Политика помогает держать поведение системы стабильным и предсказуемым.
Нужно ли сразу делить на микросервисы?
Нет. Сначала согласуется модель, затем выбираются технические границы.
Можно ли работать без очередей?
Можно, если события и реакции укладываются в один сервис и не требуют изоляции по времени. Но сама лента событий останется полезной. Она яснее любых схем базы данных.
Небольшой пример перевода в критерии тестирования
Команда оформить заказ имеет предусловия. Корзина не пуста, клиент идентифицирован. Ожидаемое событие — заказ создан. Политика при этом событии резервирует товары. Тест звучит просто. Если корзина заполнена и клиент известен, при вызове POST orders система фиксирует событие заказ создан, публикует задачу на резерв и возвращает идентификатор заказа. Если корзина пуста, команда отклоняется с понятным кодом ошибки. Такие формулировки одинаково читаемы бизнесом и разработкой.
Итог
Event Storming возвращает обсуждение к фактам и делает разговор предметным. События дают основу, команды объясняют намерения и точки входа, политики описывают автоматические реакции, а границы контекстов разводят ответственность. После сессии у команды на руках не абстрактные лозунги, а конкретная лента событий, понятные интерфейсы, список обработчиков, проверяемые инварианты и словарь. С таким набором решение собирается быстрее, а изменения не ломают уже согласованное поведение .
