Event Storming: исследуйте поведение до проектирования кода

Форматы Event Storming

Big Picture охватывает всю предметную область и помогает увидеть основные потоки, внешние системы, организационные границы и проблемные зоны. Process Level подробно рассматривает один бизнес-процесс: команды, события, решения, исключения и участников. Design Level приближает результат к программной модели и помогает определить агрегаты, политики, саги и модели чтения.

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

• Big Picture — общая картина домена
• Process Level — один процесс и варианты его выполнения
• Design Level — решения, агрегаты и реакции системы

Элементы модели и их смысл

Доменное событие формулируется в прошедшем времени и обозначает значимый для бизнеса факт: OrderPlaced, PaymentDeclined, TicketEscalated. Команда выражает намерение изменить систему: PlaceOrder, CapturePayment, EscalateTicket. Actor указывает, кто инициирует намерение, а политика описывает автоматическую реакцию на факт.

Read Model показывает информацию, необходимую человеку или системе для принятия решения. External System обозначает участника за пределами моделируемой ответственности. Hotspot фиксирует вопрос, конфликт или неизвестность, которые нельзя молча превращать в архитектурное предположение.

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

Пригласите людей, которые знают процесс с разных сторон: экспертов предметной области, разработчиков, поддержку, операции и владельца продукта. Начните с индивидуального добавления событий, чтобы мнение самого уверенного участника не определило всю модель. Затем выстройте события по времени, найдите альтернативные ветви и только после этого добавляйте причины и реакции.

Фасилитатор не должен заранее навязывать модель. Его задача — уточнять смысл, находить разные определения одного термина и возвращать обсуждение к реальному поведению бизнеса. Ограничивайте сессию конкретной целью и фиксируйте открытые вопросы с владельцами и следующими действиями.

Временная шкала, ветвления и ошибки

Бизнес-процесс редко является одной счастливой последовательностью. Покажите отказ оплаты, отсутствие товара, отмену пользователем, истечение срока ожидания и ручное вмешательство. Именно на альтернативных ветвях обнаруживаются важные инварианты, компенсации и требования к наблюдаемости.

Различайте порядок бизнес-фактов и технический порядок доставки сообщений. Event Storming описывает, что должно произойти и почему; гарантии очереди, повторы и транзакции проектируются позже.

Как находить границы контекстов

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

После сессии перенесите найденные отношения на Context Map и определите, какие факты контекст публикует, какие команды принимает и где необходим Anti-Corruption Layer.

От Event Storming к модели DDDesigner

Очистите дублирующиеся события, согласуйте термины и свяжите каждую команду с агрегатом, который её обрабатывает. События и команды вокруг одного набора немедленных инвариантов становятся кандидатом в агрегат. Автоматические реакции оформляются как политику, длительные процессы со своим состоянием — как сагу, а информация для экранов и отчётов — как проекцию.

Business Action связывает пользовательское намерение с начальной командой или маршрутом и ожидаемыми результатами. Это позволяет не только сохранить воркшоп, но и структурно проверить, что спроектированный поток достигает нужного бизнес-результата.

Частые ошибки

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

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

Чек-лист результата Event Storming

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

• События являются значимыми бизнес-фактами?
• Команды выражают намерения, а не технические вызовы?
• Показаны альтернативные и ошибочные ветви?
• Указано, кто принимает ключевые решения?
• Hotspot имеют владельцев и следующие действия?
• Найдены кандидаты в контексты, агрегаты, политики и саги?
• Результат перенесён в поддерживаемую модель?