Event Storming как способ вскрыть коллективную галлюцинацию команды

Я использую Event Storming не как способ построить модель,
а как способ сломать иллюзию, что мы уже всё поняли.

Проблема не в технике.
Проблема в том, что «правильный» Event Storming слишком рано создаёт ощущение ясности: полдня воркшопа, стикеры по цветам, аккуратный таймлайн — и всем кажется, что работа сделана. Ощущение есть. Понимания — нет.

Я начинаю Event Storming с вопроса, который сразу портит настроение:

Что на самом деле произошло?

Не по регламенту. Не «как должно быть». А в конкретный момент времени.

И вот тут быстро начинается балаган. Аналитик говорит: «Заказ создан». Техлид поправляет: «В базе появился черновик со статусом draft». Интеграционщик добавляет: «Вообще-то всё началось с вебхука от эквайринга». Все вроде говорят об одном, но между этими «одинаковыми» событиями — минуты лага, ретраи, падения и места, где система ведёт себя как хочет. Это не детали. Это разные реальности, которые по случайности называют одним словом.

Следующий вопрос обычно добивает окончательно:

А что мы вообще считаем событием?

Для бизнеса событие — «Продажа состоялась». Для разработки — «paid = true в таблице orders». Для аналитики — «данные стали консистентны». Слово одно, смыслы разные. И пока это не вынесено на доску, любая аккуратная схема — просто компромисс между недоговорённостями, замаскированный под архитектуру.

Поэтому мой Event Storming:
• начинается без таймлайна
• допускает дубли и противоречия
• сознательно игнорирует «как правильно по DDD»

Я не чиню хаос. Я сначала проверяю, видим ли мы его вообще.

И почти всегда всплывает коллективная галлюцинация команды. Например, бизнес уверен, что пользователь «просто ждёт подтверждения». А по логам видно — он жмёт «Оплатить» три раза, система создаёт три черновика заказа, архитекторы в это время рисуют идеальный state transition, а тётя Галя из саппорта потом вручную удаляет дубли в админке, потому что «иначе отчёт не сходится».

Вот это и есть ваш реальный Event Storming. Не на стикерах, а в живой системе.

В схемах этого поведения нет.
В документации — тоже.
Зато без него ничего не работает.

Я почти никогда не довожу такой Event Storming до красоты. Потому что аккуратная схема на этом этапе — это способ слишком рано себя успокоить. Если после сессии всем стало «понятно», значит, мы что-то важное не заметили.

В следующем посте — про самое неприятное: как Event Storming очень быстро показывает места, где мы проектируем поведение, которого в системе не существует, и почему именно там потом происходят самые дорогие фейлы.