Когда тебе в голову приходит идея "Давайте проведём Event Storming", обычно слышишь два типа реакции: одни радостно готовят стикеры и маркеры, другие крутят пальцем у виска в стиле «опять эти ритуалы», поверили???? Т.е. реально у вас в команде все такие прошаренные и знают об этом? У меня за плечами не один "штурм событий", так что поделюсь личным опытом, чего хорошего и не очень вас может ждать.

💪📈Плюсы
1. Общее понимание домена.
Все, от разработчика до бизнес-аналитика, наконец-то начинают говорить на одном языке. Когда видишь события визуально, инсайты приходят даже к тем, кто до этого «молчал в тряпочку», те самые коллеги, которые не отсвечивают, но вспоминаешь о них, когда начинаются сборы не "др"
2. Выявление пробелов и конфликтов.
«А что происходит после того, как оплата прошла?» – «Э-э, не знаю…» Этот диалог лучше всплывёт на встрече, чем на продакшене.
3. Ускоряет командное взаимодействие.
У вас появляется общая доска с «картиной мира», и ребята охотнее обсуждают спорные места, потому что всё видно, как на ладони.
4. Повышение вовлечённости.
Кто любит бумажки, тот счастлив, что можно лепить стикеры. Кто ненавидит бумажки – вдруг понимает, что так идея «оцифровывается» быстрее, чем долгими разговорами.

😆😆Минусы
1. Затраты времени.
«Штурм событий» может занять пару часов, а то и целый день. Некоторые (особенно интровертные) разработчики могут предпочесть это время тратить на реальный код.
2. Риск увязнуть в деталях.
Если модератор не «рубит» бесполезные ветвления, сессия превращается в бесконечные дискуссии о названиях ивентов.
3. Нужен толковый фасилитатор.
Без активного ведущего можно получить хаос: кто-то будет «подминать» под себя, кто-то вообще молча прятаться.
4. Иллюзия завершённости.
Даже если вы всё круто расписали на доске, это лишь «снимок» ситуации. Процесс надо постоянно пересматривать, а не считать, что «всё, мы изучили ивенты навечно».

Итог, ну или как бы логическое умозаключение
Event Storming – мощный инструмент, который объединяет людей вокруг единого понимания системы. Но это не магия, которая решит все проблемы за пару часов стикеротерапии. Важно, чтобы у вас был человек, способный направлять обсуждение, и готовность затем поддерживать модель в актуальном состоянии. Зато, если подойти к делу с умом, вы избежите внезапных «белых пятен» в логике и улучшите командное взаимодействие.

P.S. Если после сессии кто-то приклеит себе на лоб стикер «PaymentFailed» – это нормально. Главное, чтобы он понимал, как этот ивент ведёт к «PaymentRetried» и «PaymentSucceeded».