Какие предметы вамнравились в школе? Я очень любила математику. Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами — единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.
Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.
Для этого необходимо организовать совместное исследование сложной предметной области бизнеса: собрать команду, построить модель процессов и сверить свои гипотезы с реальными знаниями экспертов. По моему опыту, снизить неопределенность в понимании предметной области и проверить предположения на соответствие действительности помогает — Event Storming. Эта техника выявляет и минимизирует влияние ошибочных предположений на качество конечного продукта.
Поддомены и ограниченные контексты
У многих людей Event Storming ассоциируется с DDD (предметно-ориентированным проектированием), но я не буду привязываться к подходам, потому что эта техника работает со всеми. Мы не станем строго фиксировать этапы проектирования, а обобщенно скажем, что на первом этапе важно погрузиться в предметную область и ее бизнес-процессы, чтобы предположения соответствовали действительности.
В каждом бизнесе есть поддомены — чётко выделенные сегменты деловой активности. Из всех поддоменов формируется предметная область компании. Те самые услуги, которые она предоставляет клиентам. В рамках поддомена или даже бизнес-процесса у одного и того же термина может быть разное значение. Например, лид для отдела продаж — потенциальный клиент, а лид для доставки — это заявка или запрос, инициирующий логистическую операцию.
На втором этапе важно создать единый язык для каждого контекста, чтобы все участники процесса одинаково понимали ключевые термины и процессы. Например, бизнес будет говорить: «доставка по адресу возможна, если есть доступные курьеры», а не: «доставка по адресу возможна, если в таблице «couriers» найдена запись с признаком «is_active=true».
На третьем этапе выделяются ограниченные контексты. Их границы могут быть широкими, в соответствии с контекстами самой предметной области. Например, контекст продаж и контекст доставки. Или узкими, при разделении предметной области на менее крупные области задач. Например, вместо контекста доставки мы выделим контексты доставки через маркетплейсы и доставки курьерской службой. Поддомен похож на набор взаимосвязанных сценариев использования, которые определяются предметной областью. Требования к программным продуктам определяет бизнес, а вот ограниченные контексты появляются в процессе проектирования, и их выделяют разработчики. Чтобы перейти от бизнесовых поддоменов к ограниченным контекстам, нужно хорошо понимать предметную область и составить ее модель. В этом вопросе не получится изолироваться от коллег как бизнес-экспертов домена, так и членов Agile-команды. Так как разработка эффективных программных решений невозможна без единого понимания задачи.
Стремление к слабой связанности
При проектировании системы мы хотим упаковать всю сложность внутри сервисов, оставляя между ними слабую связь. На практике этого можно добиться, найдя точки слабой связи в самом бизнес-процессе — то есть определив ограниченные контексты. Для поиска таких точек и обмена знаниями о предметной области отлично подходит техника Event Storming.
Что такое Event Storming
Event Storming разработал Альберто Брандолини. Это гибкий формат воркшопов для совместного исследования сложных предметных областей экспертами предметной области и командой разработки. Он может применяться для нескольких целей:
Моделирование и улучшение сложных бизнес-процессов
Изучение или восстановление знаний о предметной области
Единое понимание о предметной области у всей команды разработки
Проектирование системы по DDD (domain-driven design)
У Event Storming простая нотация, которая состоит из набора концепций. Чтобы их было проще различать на доске Miro, Figma или любой другой, у каждой концепции свой цвет.
Можно выделить 3 уровня исследования:
Общая картина (Big Picture)
Моделирование процесса (Process Modelling)
Проектирование системы (Software Design)
На каждом уровне используется свой набор концепций: в «Общей картине» — базовые карточки, в «Проектировании системы» — участвуют все концепции.
Подготовка к Event Storming: роли и организация
Для проведения сессии Event Storming нужно собрать команду разработки и бизнес-экспертов в одном пространстве (реальном или виртуальном). Ценность Event Storming в том, чтобы задать все вопросы по процессу и получить ответы «из первых рук». Поэтому на сессии Event Storming разработчики не должны обсуждать бизнес-процесс, без представителей от бизнеса.
Кто должен участвовать:
Фасилитатор: ведёт сессию, объясняет правила, следит за динамикой, помогает участникам фокусироваться на цели и вовремя корректирует процесс.
Люди с вопросами: команда разработки, которой нужно понять, как работает бизнес-процесс.
Люди с ответами: эксперты предметной области, менеджеры, представители продаж и других бизнес-функций.
Оптимальное количество участников — 4-8 человек, чтобы обеспечить вовлечённость и управляемость обсуждения.
Что подготовить:
Большая поверхность для моделирования (бумага, доска, виртуальная доска).
Много разноцветных стикеров (оранжевые, синие, жёлтые, зелёные, фиолетовые и др.).
Маркеры для всех участников (для оффлайн сессии).
Как проходит Event Storming: структура этапов
Процесс начинается с мозгового штурма. Сначала участники выявляют все события, происходящие в бизнесе или процессе, а затем размещают их на временной шкале в хронологическом порядке. После этого фиксируют ключевые термины, которые использует бизнес. Далее к модели добавляют действующих лиц и внешние системы, а потом указывают команды, которые приводят к возникновению событий, и бизнес-правила, которые их вызывают. На заключительном этапе модель дополняют бизнес-правилами и моделями чтения, чтобы сделать её более точной и полной.
Событие (domain event, оранжевые стикеры). Формулируются в прошедшем времени («товар добавлен в корзину», «платёж получен»).
Вопросы/риски (hot spot, красные стикеры) – возможные проблемы в процессе. Вопрос, идея, комментарий.
Актор (actor, бледно-желтые стикеры) – человек, задействованный в процессе, выполняющий действие (команду) приводящее к событию (актор, пользователь, роль, персона).
Внешняя система (external system, розовые стикеры) — внешняя система, задействованная в процессе.
Термин (term, серые стикеры) — определение термина из бизнес-процесса, важного для единого понимания всей команды.
Бизнес-правило (policy, фиолетовые стикеры) — реакция в формулировке: «если произошло А, то делаем Б». Может быть как ручным, так и автоматизированным процессом.
Команда (command, синие стикеры) — действия, происходящие в системе, которые представляют намерения или пользовательские решения. Команда, выполняемая пользователем через интерфейс, воздействует на агрегат после исполнения логики, в котором порождаются доменные события.
Модель чтения (read model, зелёные стикеры) — информация, которая должна быть доступна для принятия решения актором.
Агрегат (aggregate, желтые стикеры) — это термин из DDD, который означает кластер сущностей. Мы работаем с ним как с единым целым. Кластер сущностей обладает инвариантом для группы объектов, а не единичного объекта.
Простая нотация помогает сосредоточиться на исследовании и сформировать общий язык между разработкой и бизнесом. В итоге код, дизайн и архитектура получают модель, которая построена вокруг предметной области и отражает реальность.
При проектировании системы мы стремимся добиться слабой связанности между её компонентами. Поэтому там, где не требуется строгая согласованность, выбираем асинхронные взаимодействия. Методика Event Storming отлично помогает построить модель, основанную на событиях, поскольку событие — это ключевая концепция.
Пример применения
Например, команда разрабатывает систему по курьерской доставке продуктов. На сессии Event Storming участники фиксируют события: «заявка на доставку создана», «оплата получена», «назначен курьер», «курьер в пути», «заказ доставлен». Выстраивают их в хронологическом порядке, описывают термины, например, чем «заявка» отличается от «заказа». Затем определяют, кто инициирует эти события (клиент, система по маршрутизации заявок, курьер), какие команды их вызывают («создать заявку на доставку», «взять заказ на доставку в работу», «начать заказ на доставку», «завершить заказ на доставку»). Описывают по каким правилам вызываются команды («заявка назначается на самого ближайшего свободного курьера») и какие агрегаты участвуют («Заявка на доставку», «Заказ на доставку»). В процессе обсуждения выявляются слабые связи, уточняются бизнес-правила и формируется единая терминология.
Работа с результатами и дальнейшие шаги
Итогом сессии Event Storming становится готовый артефакт, который может быть полезен для всей команды:
Архитекторы и разработчики получают доменную модель, список событий, агрегатов, команд и моделей чтения, основу для проектирования API и архитектуры.
Продукт-овнеры видят команды как элементы бэклога, события как части бизнес-процесса, бизнес-правила и единую терминологию.
Тестировщики используют события, команды и бизнес-правила для создания тестовых сценариев.
DevOps-инженеры используют выделенные ограниченные контексты для построения delivery pipeline.
В дальнейшем модель можно использовать для проектирования микросервисов, уточнения архитектуры, формирования задач и оценки рисков.
Типичные ошибки и рекомендации
Нотация Event Storming проста и понятна. Существует множество статей и докладов, посвящённых эффективному проведению таких сессий. Однако, как и в любом деле, на практике есть свои нюансы. Поэтому лучше один раз попробовать провести Event Storming, чем много раз читать или слушать о том, как это делают другие. Но перед этим стоит ознакомиться с типичными ошибками, чтобы не «наступать на грабли»:
Не все ключевые участники приглашены — обязательно должны быть как эксперты бизнеса, так и технические специалисты.
Слишком много или мало участников — оптимально 4–8 человек.
Отсутствие фасилитатора — без ведущего сессия может потерять фокус и эффективность.
Недостаточная подготовка материалов: нехватка стикеров, маркеров или места для моделирования мешает процессу.
Использование технического жаргона — важно формулировать события и термины в бизнес-логике, а не в терминах реализации.
Заключение
Event Storming — это мощный и гибкий инструмент для совместного исследования и моделирования бизнес-процессов и систем. Он помогает командам разработки изучить предметную область, сформировать единый язык с бизнесом. Смоделировать фундамент под архитектуру.
Источники и подробные гайды по подготовке и проведению Event Storming можно найти в открытых ресурсах и книге Альберто Брандолини, а также в статьях и презентациях по теме.