*вольный перевод статьи (некоторые части не переводились, некоторые были взяты из других источников, если в них данный шаг был описан подробнее)

EventStorming — это эффективный метод декомпозиции монолитного приложения и выработки четкого и последовательного подхода к созданию новой событийно-ориентированной микросервисной версии. Данный метод был предложен Альберто Брандолини в 2013 году, когда он опубликовал первую статью о EventStorming. Этот подход основан на проведении воркшопов, направленных на генерацию обсуждений и повышение прозрачности сложных бизнес-процессов. EventStorming позволяет разобрать бизнес-процесс, выявляя ключевые события, процессы, участников, политики и системы, задействованные в нем.

С момента появления EventStorming были разработаны различные его вариации. Например, IBM представила расширенную версию и ввела термин Insights Storming, добавив к стандартному процессу этап анализа потенциальных будущих событий. В свою очередь, VMWare Tanzu предложила упрощенную версию, исключив из процесса такие элементы, как политики и артефакты. Основная идея здесь заключается в том, что EventStorming не имеет строго фиксированного формата. Его основная цель — упрощение обмена знаниями, а компании могут адаптировать этот метод в зависимости от своих бизнес-задач и структуры команд. В данной статье мы рассмотрим базовый подход к EventStorming, который подходит большинству команд.

Прежде чем углубляться в детали, разберем основные компоненты и терминологию, часто используемую в EventStorming. Каждый компонент в этом процессе представлен цветными стикерами, где каждому цвету соответствует определенный тип элемента. В следующих разделах будет приведена легенда с описанием цветовых сочетаний, использованных в статье.

Компоненты и описание

События домена (оранжевый)

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

• Товар добавлен в корзину
• Корзина оформлена
• Применен скидочный код
• Заказ получен
• Оплата завершена

Команды (синий)

Определяет триггер для каждого события. Например:

• Нажатие покупателем кнопки "Оформить заказ"
• Запуск запланированной задачи системой

Акторы (желтый)

Пользователи, которые отправляют команды или получают уведомления от процесса. Следует уточнять конкретные роли, например:

• Клиент
• Менеджер склада
• Сотрудник отдела продаж

Системы (розовый)

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

• Внешний платежный шлюз
• Сервис SMS-уведомлений
• Внешний API реселлера

Политики (фиолетовый)

Набор правил, определяющих последующие шаги после события. Например:

• Что происходит после успешного платежа?
• Что происходит в случае ошибки платежа?

Артефакты (зеленый)

Значимые выходные данные, сгенерированные в результате событий.

*в некоторых других статьях о EventStorming зелёные стикеры используются для представлений (View), это помогает визуализировать, как пользователи взаимодействуют с системой, что особенно полезно на этапе проектирования пользовательского опыта - примечание от переводчика)

Временная шкала

Последовательный поток событий в рамках бизнес-процесса.