Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной).
Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах. Я проводил Event Storming 4 раза с разными командами. Чтобы объяснить участникам смысл происходящего, для каждой команды перед началом мероприятия я делал презентацию. Но оказалось, что пока не начнешь таскать карточки, выстраивать бизнес-процессы и накидывать акторы ― объяснить процесс практически невозможно.
Что такое Event Storming
Альберто Брандолини, который придумал Event Storming, описывает его так: это способ собрать вместе разработчиков и представителей бизнеса для совместного исследования предметной области и потратить на это «часы вместо дней и недель». По факту, это возможность спроектировать систему в виде бизнес-процессов и разделить ее на ограниченные контекстные модули, из которых впоследствии можно построить архитектуру.
Вот пример того, как выглядят бизнес-процессы, которые протекают внутри наших сервисов:
На схеме результат Event Storming’а c командой, которая эти сервисы поддерживает. Понимаю, что ничего не видно и не понятно. Позже я подробно расскажу об этой работе и ещё двух других. Но сначала поговорим о том, кто нужен для проведения Event Storming-сессии.
Кого позвать на Event Storming
Нам нужны:
представители бизнеса ― ПМ, аналитик, техподдержка, отдел продаж и др.;
представители разработки ― backend, frontend, архитектор и др.;
фасилитатор процесса.
Во всех примерах из статьи я выступал в роли фасилитатора. Так как я еще и архитектор, сначала получалось не очень: фасилитатор не должен высказывать своё мнение, а мне не всегда удавалось сдержаться. В такие моменты главное вовремя себя остановить, чтобы дискуссия не перешла в полемику.
Теперь немного о том, из чего состоит Event Storming и через какие нужно будет пройти.
Из чего состоит Event Storming
Вот базовые блоки:
события;
агрегаты ― сущности в ограниченном контексте. Например, корзина или товар на витрине;
акторы ― те, кто пользуются событием или являются его заказчиком. Например, пользователь, менеджер, разработчик, скрипт или внешний вызов API;
действия ― то, что мы рассматриваем как бизнес-процесс. Например, покупка продукта клиентом на сайте. В случае этого бизнес-процесса действия ― это всё, что происходит с того момента, как клиент зашел на сайт, и до того момента, когда он положил товар в корзину.
Сама сессия Event Storming’а проходит в несколько этапов.
Этап 1. Шторминг событий
На этом этапе генерируются все возможные события: клиент зашел на сайт, клиент нажал на кнопку «Положить в корзину», клиент нажал на кнопку «Перезапустить сервер». В общем, генерим всё, что приходит в голову. Для каждого события клеим/добавляем на доску стикеры:
Исходя из собственного опыта, хочу сказать, что людям, которых мы собрали на шторминг, тяжело сфокусироваться на чем-то конкретном из-за большого количества всевозможных событий. Каждый только и думает, за что взяться и с чего начать. Это происходит, даже если вы провели предварительную мини-презентацию с рассказом о том, что и как делать. Чтобы избежать расфокусировки, советую направлять участников при помощи связанных между собой событий или определенных направлений. Например:
что происходит в корзине и какие там есть события,
какие события могут быть в личном кабинете у услуги домена,
какие события могут быть при оплате и т. д.
Это позволит сразу сконцентрироваться на чём-то конкретном, вместо того, чтобы пытаться охватить и вспомнить всё, что есть.
Важно понимать, что события могут повторяться и при этом их нельзя выкидывать, так как они могут быть в разных контекстах от разных акторов. Например, очистить корзину может клиент, а может и менеджер, и в обоих случаях внутренние процессы происходят по-разному.
Не бойтесь добавлять те события, в которых вы не уверены. Вы разберете их на следующих этапах и в результате поймете, важное ли это событие или нет. Выгружайте всё, что приходит в голову.
Этап 2. Разбор событий в хронологическом порядке
Если на предыдущем этапе мы только генерировали события, то сейчас их нужно выстроить в хронологическом порядке. Это нужно для того, чтобы понять, как происходит конкретный бизнес-процесс.
Этап 3. Добавление акторов, действий и агрегатов
Достаточно сложный этап из-за понимания такой сущности, как агрегат. Это понятие может оказаться достаточно сложным в понимании и для бизнеса, и для разработки.
Пример:
Где:
«Выбрал товар», «Добавил в корзину» и «etc» ― это события;
«User» ― актор, который инициирует событие;
«Покупка» ― действие;
«Витрина», «Корзина» и «Агрегат» ― агрегаты. На их основе в дальнейшем будем строить ограниченные контексты, группировки и т. д.
Этап 4. Работа с результатами
В итоге мы получаем агрегаты в изолированных контекстах и события, за которые эти агрегаты отвечают. Ниже в примерах я расскажу, как с результатами работали мы и что нам это дало.
Это, в принципе, и есть вся основа Event Storming.
Чем полезен Event Storming
Самая главная польза Event Storming ― это синхронизация между бизнесом и разработкой. Когда вы проговариваете все бизнес-процессы, которые у вас есть, вы:
Формируете общий для бизнеса и разработки словарь.
Даете разработке понять, что хочет бизнес, а бизнесу понять разработку и ограничения системы.
-
Формируете определение и структурное разделение сущностей системы на модули:
Это те самые акторы, которые отвечают за какой-то набор событий в разных контекстах пользователей. Это помогает трезво взглянуть на ситуацию и понять, например, что у вас есть сервис, который отвечает и за клиентскую часть, и за админскую, а ещё к нему ходят какие-то внешние системы и всё это в одной кодовой базе. -
Дизайните бизнес-процессы. Все понимают, что и как происходит, и обо всём договариваются:
Быстро оцениваете сущность, ее важность, зависимости и сложности. Например, бизнес хочет, чтобы разработчики сделали ракету. Но тесный контакт с разработчиками даёт понять, что ракету не построить, а бизнесу вполне подойдет бумажный самолётик.
-
На основе готовой карты легко смоделируете будущие изменения архитектуры и бизнес-процессов. У вас будет карта, которая содержит цепочки событий, и по ним можно увидеть, какие у событий есть зависимости:
Если в будущем понадобится внести серьезные изменения в архитектуру, будет видно, какие события будут затронуты и какие агрегаты от этого зависят. А если понадобится интегрировать внешнюю систему, которая заменит часть вашей, вы сможете увидеть зависимости у этой части системы, понять, что нужно будет переписывать, и прикинуть объемы интеграции.
-
Визуально поймете, какие узкие горлышки есть у архитектуры и бизнес-процессов:
Бизнес поймет и решит, что есть какие-то лишние манипуляции, а разработка сразу объяснит, лишние они или без них, наоборот, никак, так как от этих событий зависят другие события в будущем. В архитектуре тоже будет видно, если система построена не очень хорошо. Может быть, слишком много связанности и зависимостей у модулей, или они отвечают за слишком большое количество действий и нет разграничения по контексту. Как, например, какая-нибудь ручка, которая отвечает и за клиентскую работу, и за админскую, и за менеджерскую.
А теперь к реальным примерам.
Event Storming системы заказа серверов с нуля
Это наша самая большая работа:
Делали мы ее составом из 10 человек на протяжении примерно 3 месяцев. Собрать всех хотя бы на 3 часа было достаточно проблематично из-за плотного графика каждого участника.
Тут еще раз стоит уточнить, что мы собирались в онлайне. Конечно, эту систему придумали для проведения офлайн-мероприятий и в любой методичке по Event Storming'у вам посоветуют именно такой формат. И да, подтверждаю, лучше собраться вживую. Но из-за удалёнки и географической распределенности участников мы делали, что могли и как могли.
Вернемся к карте. Эту систему мы проектировали с нуля. У нас есть базовые блоки: система 1C, система Битрикса и наша кастомная логика, которой не существовало и которую нужно было реализовать на уровне Python-сервисов. Плюс ко всему у нас есть бизнес-процессы.
Мы видели, что есть пользователь со своим набором полей, который имеет свои договоры с нами как с поставщиком. Вроде всё понятно: есть пользователь и его, наверное, стоит засунуть в Битрикс, потому что там пользователи тоже есть. Мы разобрали бизнес-процессы и поняли, что в Битрикс это вообще не влезает и это отдельная сущность, за которую должны отвечать отдельные люди и должны это делать вне Битрикса через отдельный модуль.
Также мы разграничили зоны ответственности команд и выяснили, за что отвечает команда Битрикса, команда 1С и команда, которая пишет на Python. После чего мы смогли построить зависимости и связи. Стало понятно, как выгружать товары, как проводить платёжки по заказам, где брать договоры и т. д.
Перед началом мероприятия у нас не было ничего, кроме 100 страниц бизнес-требований, трех команд с разными сферами ответственности и маленьким пониманием того, за какую конкретно часть какая команда отвечает. Никто не понимал общий объем работ и схему взаимодействия.
Когда мы завершили Event Storming, каждая команда получила представление о том, что должна делать, где нужно договариваться, и вообще жизнь у ребят стала лучше. Всё было сделано с нуля, у нас не было каких-то готовых решений. За это время разработка поняла, что хочет бизнес, а бизнес понял, какие есть технические ограничения в этой системе. Я думаю, что все остались в выигрыше.
Event Storming существующей системы
Второй пример нашей работы:
Если первый пример мы создавали с нуля, то в этот раз условия были другие. Это уже существующая, рабочая и вообще замечательная система облачных серверов. Так зачем же её прогонять через Event Storming? Цель заключалась в том, чтобы составить карту продукта, на её основе спроектировать техническое развитие продукта и получить возможность внесения каких-то глобальных изменений на фоне меняющейся конъюнктуры и требований к системе.
Мы провели шторминг и закончили за 5 созвонов по 3 часа. И вот какие результаты мы получили, помимо карты продукта:
появилось понимание по агрегатам,
синхронизировались по терминам (была путаница во время шторминга),
нашли узкие горлышки (например API-ресурсы, которые умеют всё на свете).
Выводы сделаны, работа над картой продолжается.
Event Storming системы без документации
И третий пример, который сейчас в работе:
Это Domain service, который представляет собой легаси-код. Он определяет доменную услугу, что она делает, какие у неё внутри бизнес-процессы и всё такое. Давным-давно за этот сервис отвечала только одна команда. Сейчас им занимаются ребята из новой команды. Единственная корректная всеобъемлющая документация ― это код. Разработчики не могли в полной мере ответить на все вопросы. Бизнес тоже не мог. Было тяжело вытаскивать требования и формировать общую картину того, что мы будем делать. Мы еще не закончили и продолжаем работу.
Цель ― понять основные бизнес-процессы, определить связи и зависимости, определить акторов, разделить по ним бизнес-процессы и спроектировать архитектуру. Домены ― это сложно и много нюансов. Все нюансы мы не могли и не стали разбирать. Мы прорабатываем процессы над сущностями, чтобы понять, что же нам делать. К участникам приходит понимание, и пока всё нравится. С одной стороны, всем становится легче, но с другой – мы понимаем весь объем работы и он немного пугает.
Самым лучшим представителем бизнеса на этом шторминге оказалась техподдержка. Они досконально знают, как работает система и какие внутренние процессы в ней происходят. За это им отдельное спасибо.
Теперь поговорим о том, что Event Storming не может заменить.
Что не заменяет Event Storming
БТ, ТЗ и другую документацию. Конечно, если вы работаете над небольшой фичей, то наверняка сообразите, куда шлепнуть код, где соединить, и пойдёте дальше. А если это уже что-то более-менее серьезное, то без бизнес-требований, техзадания, контрактов и другой документации вы, скорее всего, попадете в производственный ад;
аналитику процессов. Вы можете накинуть что-то на шторминге, но в итоге какие-то события нужно будет убрать: что-то слишком сложно, что-то слишком дорого, а что-то не соответствует вашей маркетинговой стратегии. Поэтому без аналитики никак;
проектирование архитектуры. При моделировании архитектуры во время шторминга у вас не будет полного представления о том, какая в итоге будет архитектура. Вы не знаете, какие контракты ходят между системами, нет представления, насколько они физически друг от друга изолированы, какая авторизация и т. д. Поэтому проектирование архитектуры необходимо.