Нотация Event Storming: как читать стикеры на схеме
Одна схема, семь типов карточек и правила понятного воркшопа.
Команда использует нотацию Event Storming, но через двадцать минут цвета уже не помогают. На синей карточке появляется результат, на оранжевой действие, а соседние соединяют словами «дальше система сама». Каждый читает модель по-своему.
Нотация Event Storming задаёт общий язык для разговора о процессе. Сценарий бронирования номера и памятка помогут применить его на следующей сессии.
Event Storming допускает неточность, но не путаницу
Нотация Event Storming мягче UML и BPMN: команда уточняет модель при обсуждении. У каждого цвета есть свой вопрос. Если смешать факты, намерения и правила, связи исчезнут. Держи легенду на виду, а замену цветов согласуй с участниками.
Последовательность карточек Event Storming
Гость видит свободные номера и отправляет команду системе бронирования. Результатом становится одно из двух событий. «Номер забронирован» запускает политику предоплаты, а та приводит к команде и событиям платёжного провайдера. Процесс также может запускать время или внешняя система.
Оранжевый: доменное событие
Доменное событие (Domain Event) описывает значимый для бизнеса факт, который уже произошёл. Пиши его в прошедшем времени: «Номер забронирован», «Оплата отклонена», «Бронь отменена».
Событие показывает переход между состояниями. «Оплата» перехода не описывает, а «Оплата подтверждена» меняет состояние брони. Источником события бывает человек, внешняя система, время или реакция на предыдущее событие. Одна команда может иметь несколько исходов: показывай их отдельными событиями.
Синий: команда или намерение
Команда (Command) описывает действие, которое кто-то хочет выполнить. Пиши глагол в настоящем времени: «Забронировать номер», «Запросить оплату», «Отменить бронь».
Успех команды не гарантирован. «Забронировать номер» может закончиться событиями «Номер забронирован» или «Бронирование отклонено». Команда отвечает на вопрос «что хотим сделать?», событие отвечает на вопрос «что уже произошло?».
Жёлтый: человек или роль
Маленькая жёлтая карточка показывает того, кто выполняет действие: «Гость» или «Администратор». Детализируй роль, только когда поведение меняет процесс. Например, если постоянному гостю дают отсрочку оплаты, обобщённый «Гость» скрывает отдельную ветку.
Зелёный: модель чтения
Модель чтения (Read Model) содержит информацию для решения. Перед командой «Забронировать номер» гость должен увидеть даты, доступные номера, цену и условия отмены.
Строй модель чтения от решения: без какой информации его нельзя принять? Так на схеме останутся нужные данные, а не копия полей из базы. При необходимости список можно заменить скриншотом или вайрфреймом.
Розовый: система
Розовая карточка обозначает конкретную систему, которая получает команды или порождает события: «Система бронирования», «Платёжный провайдер», «CRM отеля».
Называй системы явно. Карточка «Внешняя система» скрывает владельца интеграции, границу ответственности и место сбоя. Обобщение допустимо, если детали не влияют на исследуемый участок процесса.
Сиреневый: политика
Политика (Policy) связывает произошедшее событие со следующей командой. Её удобно проговаривать по шаблону: «Когда [событие], тогда [команда]» или «Если [условие], то [команда]».
После события «Номер забронирован» действует правило: «Если тариф требует предоплату, запросить оплату». Без сиреневой карточки реакция выглядит автоматической, хотя за ней есть бизнес-решение. Проговори политику со словами «всегда» и «немедленно», чтобы найти исключения. Если решение принимает сотрудник, помести его жёлтую карточку на политику.
Красный или ярко-розовый: проблемное место
Hotspot отмечает вопрос, риск, противоречие или участок, который команда пока не готова разбирать. Например: «Что произойдёт, если провайдер подтвердит оплату после истечения срока брони?»
Hotspot позволяет продолжить сценарий, не потеряв проблему. Запиши вопрос и после сессии перенеси его в список решений или задач. Оттенки различаются между наборами стикеров, поэтому закрепи цвет в легенде.
Как собрать сценарий и проверить себя
Начни с событий: разложи слева направо факты, которые меняют состояние процесса. На первом проходе важнее увидеть его ход и расхождения в понимании.
Затем двигайся назад: какая команда вызвала событие, кто её отправил, какие данные использовал? Потом выясни, кто реагирует на событие, по какому правилу и какой командой.
Проверь получившуюся цепочку по пяти вопросам:
Если ответа нет, зафиксируй пробел и обратись к тому, кто знает реальный процесс.
Четыре ошибки, которые ломают модель
Нотация даёт старт, но не проектирует систему за команду
Нотация Event Storming помогает прочитать процесс, но не определяет границы сервисов, агрегаты или готовую архитектуру. Для этого нужны знания предметной области, DDD и отдельная работа с ответственностью компонентов.
Возьми один реальный сценарий длиной в пять-семь событий и разложи его по памятке. Если команда без устных пояснений видит, кто принимает решение, какие данные использует и почему возникает следующий шаг, нотация выполняет свою задачу.