Зачем нужен подход Event Storming ?

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

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

Но зачастую такие знания о процессах, которые должны происходить в системе при различных условиях, о возможных состояниях объектов в системе и условиях переходов из одного состояния в другое, не описаны в едином источнике знаний. Знания и понимание как должно быть могут немного содержаться в устаревшей документации, разумеется у product manager, project manager, у программистов и у многих других сотрудников компании, в том числе у собственника бизнеса. 

И для такого моделирования уже существуют способы разной степени сложности и затратности по времени, но на их фоне очень выгодно выделяется подход Event Storming, введеный итальянским программистом Альберто Брандолини, успешно используемый им в контексте DDD.

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

Процесс Event Storming — это способ собрать вместе всех доменных экспертов (программистов, менеджеров и других) и учиться друг у друга, чтобы через описание событий в системе получить полную картину требуемых бизнес процессов.

Главный результат — это быстрое исследование предметной области и шаринг и фиксация знаний среди заинтересованных лиц.

Дополнительно Event Storming позволяет:

  • Выявление неявных зависимостей на уровне бизнеса.
  • Поиск пропущенных событий.

  • Поднимать сложные вопросы о поведении пользователя еще на этапе идеи, чтобы не разрабатывать системы, которые не удовлетворяют потребностям клиентов нашего бизнеса.

  • Хорошая исходная точка для моделирования бизнес-процесс на DDD, за счет использования похожей терминологии.

Составные элементы event storming — один элемент — один стикер:

  • Пользователь Actor (желтый маленький стикер) — человек, выполняющий команду через представление.
  • Команда (синий стикер) — это команда, выполняемая пользователем через представление агрегата, которая приводит к созданию события домена.
  • Агрегат (желтый большой стикер) — совокупность объектов домена, которые можно рассматривать как единое целое.
  • Внешняя система (розовый стикер) — сторонний поставщик услуг, например платежный шлюз или транспортная компания.
  • Бизнес-процесс (фиолетовый стикер) — обрабатывает команду в соответствии с бизнес-правилами и логикой. Создает одно или несколько доменных событий.
  • Событие домена (оранжевый стикер) — это событие, происходящее в бизнес-процессе. Пишется в прошедшем времени, как свершившийся факт.
  • Представление (зеленый стикер) — это представление, с которым пользователи взаимодействуют для выполнения задачи в системе. Команды

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

Что нужно для проведения?

  1. Неограниченная поверхность — физическая стена или доска на https://miro.com 
  2. Разбиение на группы не более 4-х человек с разными экспертами внутри команды (люди с вопросами и люди с ответами). Event Storming должен описывать реальную модель процессов в бизнесе, для этого нужны представители от бизнеса.
  3. Много стикеров
  4. Много маркеров, для каждого участника.
  5. Обязательно, чтобы каждый написал (отразил) хотя бы одно событие.
  6. Во время Эвент Шторминга будут возникать Вопросы и Предположения — мы их долго не обсуждаем — записываем для дальнейшего уточнения в нерамках текущей сессии эвент шторминга.

Вопросы — ключ к выяснению бизнес процесса.

  • Что должно произойти, чтобы произошло это событие?
  • Это происходит всегда или иногда?
  • Что произойдет, если что-то пойдет не так, как задумано?

Итерация 1.

Результат итерации: найдены все-все доменные события бизнес-системы.

  1. Приводим краткую теорию и пример: что есть кто-то, он может вызвать команду, какие события происходят? События — действия в системе, которые уже произошли в прошлом как факт и не могут быть отменены, например: товар оплачен, пользователь добавил товар в корзину  и т.д.
  2. Выписываем все события в рамках домена (также в рамках всего бизнеса).
  3. Размещаем события по шкале времени слева — направо.
  4. Проигрываем события в обратную сторону спарва — налево. Например Товар оплачен, что этому предшествовало (какое событие) ? 

Итерация 2. 

Результат итерации: найдены все-все команды, вызвавшие события из итерации 1 и экторы, выполняющие команды.

  1. Группы перемешиваются новыми участниками по 3 человека.
  2. Краткая теория и пример про действующих лиц actors, что они вызывают команды, команды могут быть отправлены в Агрегат или во внешнею систему, в результате выполнения команды меняется состояние в системе и генерируются события. Команды — некоторое действие в будущем времени которое меняет состояние, например: отправить уведомление, сформировать платежку. Это действие, которое может и не произойти, если не будет удовлетворять условиям в системе. Зачастую команда генерирует событие — оплатить заказ — заказ оплачен. Также бывает, что Одна Команда — может сгенерировать несколько разных событий, а также разные команды — могут привести к одному событию.
  3. Группы проигрывают процесс вперед и назад и через стикеры описывают процесс для себя, а потом проигрывают для других групп, формируя единое понимание и единый язык, а также дополняя темные пятна.

Итерация 3.

  1. Краткая теория и пример для политик и подпроцессов. Например, запрос на возврат средств — предусмотренно ли политикой — если да то возникает команда — команда например во внешнюю систему возврата — генерируются события средства возвращены. Политики вдальнейшем программисты реализуют как бизнес-правила в рамках агрегатора.
  2. Группы проигрывают процесс вперед и назад и дополняют схему политиками и процедурами 
  3. Также группы указывают уже возможные модели чтения — формируется постепенно UI.

Итерация 4

Результат итерации — определенные ограниченные контексты и агрегаты в которых выполняются команды и происходят события.

  1. Краткая теория про абстракцию Агрегат, что это совокупность сущностей, рассматриваемых как единое целое и имеющие транзакционную границу и целостность данных. Например, ордер и к нему имеются транзакции — и мы к транзакциям обращаемся не напрямую, а через агрегат Ордер. Зачастую агрегат будет фигурировать в команде.
  2. Группы проигрывают процесс вперед и назад, выявляя агрегаты и отражая их на схеме.

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

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

А по завершении Event Storming мы как программисты имеем четкие ограниченные контексты для разделения на домены и реализации DDD в нашем приложении.

Дополнительная информация:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *