Event Storming: как не терять требования в разработке

Бизнес просит «добавить отмену заказа», аналитик описывает смену статуса, а разработчик реализует endpoint. На приёмке выясняется, что после передачи курьеру отмена означает возврат денег и обращение в поддержку. Event Storming помогает найти такие расхождения до реализации.

Метод собирает разные версии процесса в одной модели и даёт команде общий язык. Разберём его на сценарии отмены заказа: от первых событий до решения, стоит ли проводить воркшоп.

Event Storming проводят как фасилитируемый воркшоп, на котором участники раскладывают значимые для бизнеса события по времени. Метод предложил Альберто Брандолини в сообществе Domain-Driven Design (DDD), но владеть DDD для участия не нужно.

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

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

Сначала участники записывают доменные события, то есть уже произошедшие бизнес-факты, на оранжевых стикерах: «Заказ оформлен», «Оплата получена». Их располагают слева направо по времени.

Синие стикеры обозначают команды, которые могут привести к событию. Жёлтый показывает человека или роль, зелёный хранит данные для решения, а сиреневый описывает правило реакции на событие. Розовым отмечают внешнюю систему, красным выделяют риск, вопрос или противоречие.

Команда выражает намерение и не гарантирует успех. После «Отменить заказ» возможны события «Заказ отменён» и «Отмена отклонена». Эта развилка сразу вызывает вопрос: кто и при каких условиях может отменять заказ?

Нотация мягче UML или BPMN, поэтому в обсуждении участвуют люди без знания формального моделирования. Точность добавляют постепенно: сначала фиксируют версии, затем устраняют дубли и уточняют термины.

Возьмём цепочку счастливого пути:

Участники добавляют команду «Отменить заказ» в разные точки процесса. До подтверждения рестораном достаточно снять резерв. После оплаты нужен возврат. После передачи курьеру слово «отмена» может означать спор, компенсацию или отказ в операции.

Рядом появляются вопросы о стоимости приготовленного блюда, возврате промокода и сбое платёжного провайдера. Их отмечают как hotspots, чтобы не потерять неопределённость. Затем добавляют данные для решения: статус приготовления, способ оплаты и правила ресторана.

Политики раскрывают реакции системы. Правило «Когда отмена подтверждена и заказ оплачен, оформить возврат» заставляет обсудить исключения: для части способов оплаты может потребоваться ручная проверка. Так одна расплывчатая функция превращается в несколько сценариев до проектирования API и таблиц.

Масштаб выбирают по вопросу. Big Picture показывает процесс целиком и границы между подразделениями. Process Modeling подробно разбирает один поток. Для отмены заказа не нужно моделировать всю компанию.

Не превращай встречу в доклад эксперта. Даже ошибочное предположение разработчика может вызвать объяснение правила, которое доменный эксперт считал само собой разумеющимся. Задача фасилитатора: поддерживать темп, давать слово разным ролям и откладывать споры вне цели встречи.

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

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

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

Карта событий не генерирует архитектуру автоматически. Она даёт материал для решений о bounded contexts, интеграциях и ответственности компонентов. Гипотезы всё равно придётся проверить с бизнесом и техническими ограничениями.

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

Чем шире охват, тем дороже встреча и выше риск утонуть в деталях. Заранее назови решение, которое должна поддержать модель: найти причину задержек, определить границы сервиса или уточнить сценарий функции.

Хороший Event Storming оставляет команде общий словарь, модель процесса и список проверяемых вопросов. Возьми одну функцию, которую участники объясняют по-разному, и проведи часовую сессию по её событиям и исключениям. Первые противоречия станут предметом следующего решения.