Одним из самых важных и сложных моментов, предшествующим разработке архитектуры приложения, это сбор требований и моделирование бизнес-процессов.
Не важно, внтутренний или внешний заказчик, не важно будет in-house или outsource разработка, вначале требуется понять ЧТО требуется сделать, КАКИЕ объекты будут в будущей системе и КАКИЕ сценарии должны происходить. И если ваше будущее приложение немного сложнее, чем красная кнопка с функционалом оставить отзыв, то в сложном бизнес-процессе будет присутствовать большое количесство объектов и вариантов сценариев с ними.
Но зачастую такие знания о процессах, которые должны происходить в системе при различных условиях, о возможных состояниях объектов в системе и условиях переходов из одного состояния в другое, не описаны в едином источнике знаний. Знания и понимание как должно быть могут немного содержаться в устаревшей документации, разумеется у product manager, project manager, у программистов и у многих других сотрудников компании, в том числе у собственника бизнеса.

И для такого моделирования уже существуют способы разной степени сложности и затратности по времени, но на их фоне очень выгодно выделяется подход Event Storming, введеный итальянским программистом Альберто Брандолини, успешно используемый им в контексте DDD.
Над большим проектом работает большое количество людей и как правило никто не видит всю картину проекта полностью, по большей части каждый знает свой модуль и немного о других модулях, но почти никогда не знают весь проект, потому что его сложно уложить в голове.
Процесс Event Storming — это способ собрать вместе всех доменных экспертов (программистов, менеджеров и других) и учиться друг у друга, чтобы через описание событий в системе получить полную картину требуемых бизнес процессов.
Главный результат — это быстрое исследование предметной области и шаринг и фиксация знаний среди заинтересованных лиц.
Дополнительно Event Storming позволяет:
- Выявление неявных зависимостей на уровне бизнеса.
-
Поиск пропущенных событий.
-
Поднимать сложные вопросы о поведении пользователя еще на этапе идеи, чтобы не разрабатывать системы, которые не удовлетворяют потребностям клиентов нашего бизнеса.
- Хорошая исходная точка для моделирования бизнес-процесс на DDD, за счет использования похожей терминологии.
Составные элементы event storming — один элемент — один стикер:
- Пользователь Actor (желтый маленький стикер) — человек, выполняющий команду через представление.
- Команда (синий стикер) — это команда, выполняемая пользователем через представление агрегата, которая приводит к созданию события домена.
- Агрегат (желтый большой стикер) — совокупность объектов домена, которые можно рассматривать как единое целое.
- Внешняя система (розовый стикер) — сторонний поставщик услуг, например платежный шлюз или транспортная компания.
- Бизнес-процесс (фиолетовый стикер) — обрабатывает команду в соответствии с бизнес-правилами и логикой. Создает одно или несколько доменных событий.
- Событие домена (оранжевый стикер) — это событие, происходящее в бизнес-процессе. Пишется в прошедшем времени, как свершившийся факт.
- Представление (зеленый стикер) — это представление, с которым пользователи взаимодействуют для выполнения задачи в системе. Команды
Для эвент-шторминга важно, чтобы присутствовали нужные люди. Сюда входят люди, которые знают вопросы, которые нужно задать (обычно разработчики), и те, кто знает ответы (эксперты в предметной области, владельцы продуктов).
Что нужно для проведения?
- Неограниченная поверхность — физическая стена или доска на https://miro.com
- Разбиение на группы не более 4-х человек с разными экспертами внутри команды (люди с вопросами и люди с ответами). Event Storming должен описывать реальную модель процессов в бизнесе, для этого нужны представители от бизнеса.
- Много стикеров
- Много маркеров, для каждого участника.
- Обязательно, чтобы каждый написал (отразил) хотя бы одно событие.
- Во время Эвент Шторминга будут возникать Вопросы и Предположения — мы их долго не обсуждаем — записываем для дальнейшего уточнения в нерамках текущей сессии эвент шторминга.
Вопросы — ключ к выяснению бизнес процесса.
- Что должно произойти, чтобы произошло это событие?
- Это происходит всегда или иногда?
- Что произойдет, если что-то пойдет не так, как задумано?
Итерация 1.
Результат итерации: найдены все-все доменные события бизнес-системы.
- Приводим краткую теорию и пример: что есть кто-то, он может вызвать команду, какие события происходят? События — действия в системе, которые уже произошли в прошлом как факт и не могут быть отменены, например: товар оплачен, пользователь добавил товар в корзину и т.д.
- Выписываем все события в рамках домена (также в рамках всего бизнеса).
- Размещаем события по шкале времени слева — направо.
- Проигрываем события в обратную сторону спарва — налево. Например Товар оплачен, что этому предшествовало (какое событие) ?
Итерация 2.
Результат итерации: найдены все-все команды, вызвавшие события из итерации 1 и экторы, выполняющие команды.
- Группы перемешиваются новыми участниками по 3 человека.
- Краткая теория и пример про действующих лиц actors, что они вызывают команды, команды могут быть отправлены в Агрегат или во внешнею систему, в результате выполнения команды меняется состояние в системе и генерируются события. Команды — некоторое действие в будущем времени которое меняет состояние, например: отправить уведомление, сформировать платежку. Это действие, которое может и не произойти, если не будет удовлетворять условиям в системе. Зачастую команда генерирует событие — оплатить заказ — заказ оплачен. Также бывает, что Одна Команда — может сгенерировать несколько разных событий, а также разные команды — могут привести к одному событию.
- Группы проигрывают процесс вперед и назад и через стикеры описывают процесс для себя, а потом проигрывают для других групп, формируя единое понимание и единый язык, а также дополняя темные пятна.
Итерация 3.
- Краткая теория и пример для политик и подпроцессов. Например, запрос на возврат средств — предусмотренно ли политикой — если да то возникает команда — команда например во внешнюю систему возврата — генерируются события средства возвращены. Политики вдальнейшем программисты реализуют как бизнес-правила в рамках агрегатора.
- Группы проигрывают процесс вперед и назад и дополняют схему политиками и процедурами
- Также группы указывают уже возможные модели чтения — формируется постепенно UI.
Итерация 4
Результат итерации — определенные ограниченные контексты и агрегаты в которых выполняются команды и происходят события.
- Краткая теория про абстракцию Агрегат, что это совокупность сущностей, рассматриваемых как единое целое и имеющие транзакционную границу и целостность данных. Например, ордер и к нему имеются транзакции — и мы к транзакциям обращаемся не напрямую, а через агрегат Ордер. Зачастую агрегат будет фигурировать в команде.
- Группы проигрывают процесс вперед и назад, выявляя агрегаты и отражая их на схеме.

Описание ограниченного контекста далее удобвно фиксировать как текст ввиде конкретной формы в конфлюенс.

Самый важный момент, что анализ предметной области происходит за часы вместо недель. Процесс происходит естественно и открыто. Эксперты предметных областей сами расказывают все нюансы и делятся информацией, программистам не приходится додумывать.
А по завершении Event Storming мы как программисты имеем четкие ограниченные контексты для разделения на домены и реализации DDD в нашем приложении.
Дополнительная информация:
- моделирование бизнес-процессов подход bpmn.
- статья 2013 года на блоге Альберто Брандолини.
- дополнительные источники на оф сайте об event storming.
- выступление 2017 года Альберто Брандолини об event storming.
- книга об event storming от Альберто Брандолини.
- доклад Сергея Баранова на митапе в Райффайзен-банке.
- статьи об event storming на сайт Сергея Баранова.
- мастер-класс Евгения Пешкова на канале DDDevotion на youtube.
- мастер-класс Сергая Баранова.
- статья в блоге ontico на habr.