Event Storming поэтапно: 1, 2…

Методология Event Storming проста и сложна одновременно.

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

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

Сложно понять как делается Event Storming. Книга автора методологии – Альберто Брандолини – в процессе написания и ее сложно достать из некоторых стран, а статьи помогают только тем, кто уже в теме. Новичков же больше путают.

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

Если в процессе чтения вы поймете, что ничего не понимаете, знайте – это нормально. В конце дам несколько ссылок на видеоматериалы. Один из них — рассказ Сергея Баранова, где он говорит про все, что тут написано, показывает процесс и приводит несколько интересных примеров из практики. Если статья запутает вас, попробуйте начать с видео, а потом вернуться.

Flow как строительный кубик Event Storming

Такую или похожую картинку можно встретить в статьях про методологию. Называют по-разному. Я слышала: “Флоу”. Это что-то вроде повторяющегося паттерна. Из таких плюс-минус одинаковых кусочков мы выстраиваем весь процесс.

Увидев картинку, человек, приученный читать слева направо и отформатированный под Impact Mapping (кто — как — что) сразу начинает строить процесс от пользователя (клиента, действующего лица, актора). Своя правда в этом есть. Процессы строятся от людей, как дорожки в парке. Но не от наличия людей в парке, а от того, как “человеки” по этому парку ходят когда у них нет никаких дорожек. Вот и в Event Storming все строится не от людей, и не от задач, а от того, куда мы должны прийти – от событий.

Легенда Event Storming: из чего мы строим процессы и системы

Условный Флоу содержит стикеры разного цвета и это неслучайно, как и то, в каком порядке они стоят. Давайте разберемся чем мы оперируем при построении систем и проходящих в них процессов.

Event – ответ на вопрос: “Что должно случиться?” Формулируется в форме прошедшего времени так, как будто оно уже произошло.

Основная сущность методологии. Всех остальных стикеров в готовом артефакте может и не быть. Event есть всегда.

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

— подсветить какую-то важную информацию, которая может пригодиться на следующих этапах;
— пояснить какое-то событие;
— “выгрузить” из головы доменного эксперта важные замечания, пока к нему есть доступ;
— и тому подобных вещей.

Комментарий — вспомогательная сущность. Его может не быть вообще.

Term – карточка для термина. Между Event Storming и DDD часто ставят знак равно. Методология построена так, что принципы Domain-Driven Design соблюдаются как бы сами собой.

В русскоязычном сегменте принято записывать термин кириллицей и тут же в скобках – латиницей. Латинский вариант будут использовать разработчики в коде. Определение пишем как обычно. Главное – не переругаться в процессе.

Несмотря на то, что Term – вспомогательная карточка, которая даже не используется в построении процесса, определение терминологии – очень важная часть. У нее несколько задач:
— подсветить границу контекстов (места с низкой связностью);
— помочь договориться о том, что именно мы делаем не смотря на разные точки зрения;
— это одна из тех вещей, которая помогает спроектировать нелагающую систему.

Actor \ User – живой человек, выполняющий какую-то роль. Он может быть покупателем в интернет-магазине, если мы проектируем магазин, а может быть администратором, или директором. Важно, что это именно человек, а не какая-то система.

Человек – основная сущность методологии, но в условном Флоу этот стикер может отсутствовать, если инициация события обеспечивается не человеком, а системой.

External System – система, внешняя по отношению к той, что мы проектируем. Допустим, мы заранее решили, что будем пользоваться каким-то коробочным решением для авторизации пользователей. Эта “коробка” как-то уже спроектирована и мы не можем менять процессы, в ней происходящие. Поэтому мы воспринимаем эту систему как условный черный ящик в который мы что-то иногда отправляем и что-то оттуда, иногда, получаем.

Размещаем кубик внешней системы там, где он участвует в проектируемом нами процессе. External System – основная сущность методологии, но может отсутствовать в строительном кирпичике Флоу.

Модель чтения – чаще всего, экранная форма. Но это потому, что Event Storming обычно применяется для проектирования IT-систем. На самом деле это может быть договор, рекламный баннер, доставленное голубем письмо – считываемая информация в любой форме проявления.

Основная сущность методологии, но может отсутствовать во Флоу, где задействована внешняя система.

Команда – это некоторое распоряжение, которое делает user или система. Форма записи зависит от того, какого уровня процесс мы проектируем. Руководитель верхнего звена может дать команду: “Прекратить это безобразие”. В то время как на уровне исполнителя команда может выглядеть: “Создать папку”. По факту исполнения команды должно что-то случиться. Например: “Папка создана”. Поэтому команды добавляются на доску после того, как все Event проработаны. То есть это основная сущность второго этапа Event Storming.

Policy – бизнес-правило, которое уже существует и влияет на процессы.

Чаще всего этот стикер появляется там, где у нас распараллеливаются процессы: “Если на сайте зарегистрировался новый пользователь, администратор сайта получает уведомление”.

Aggregate – никто не знает что это такое, но он обязательно есть.

Я для себя определяю агрегат как объект воздействия. Когда актор считывает какую-то информацию и дает распоряжение, то меняется какой-то объект, что приводит к событию, записанному на оранжевом стикере.

Агрегат – появляется на самом последнем слое Event Storming, на третьем этапе. В этом процессе участвуют те, кто знаком с ООП, – как правило, разработчики.

Теперь вы знаете что обозначает каждый цвет стикера. Попробуйте прочитать этот шуточный Флоу.

В моем представлении это должно было выглядеть примерно так:

Некий человек считывает информацию обратного отсчета и дает команду: ”Поехали”. Команда инициирует работу агрегата “Ступени ракеты”. В результате некоторых процессов происходит событие “Ступени ракеты отвалились”. Далее у нас могут быть варианты.

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

Хочется верить, что задумка удалась: у меня получилось отразить процесс в понятной форме, а у вас – прочитать его.

Три этапа Event Storming

Как Вы успели заметить, вся работа по методологии делиться на три этапа:

Big Picture – выявление процессов, происходящих в системе
Process Modeling – построение модели системы
Software Design – на этом этапе определяют где и как будут хранить данные, как обрабатывать, как и куда передавать. Благодаря ранее проделанной работе здесь уже понятны точки слабой связности и очевидна структура модулей (микросервисов, если нужно).

В легенде, которую я привожу выше, каждый стикер принадлежит определенному этапу. Но тут я оказываю вам “медвежью услугу”. На самом деле стикеры не делятся по этапам. Например, я часто использую Policy (бизнес-правило) на самом первом этапе так как мне важно понимать причины разделения потоков. В моих артефактах фиолетовые стикеры появляются даже раньше, чему туда будут добавлены Actor (Человек).

Этапы Event Storming делятся по смыслам, а не по стикерам, но стикеры примерно по этапам распределить можно потому, что так легче запомнить в каком порядке заполняется слоеный пирог Flow.

Почему важен порядок работы со стикерами разного цвета и для чего выделены этапы:

На этапе Big Picture любые стикеры кроме оранжевых в цепочке событий могут помешать или затруднить проверку проработанного процесса методом прямого и обратного чтения. Цель этого этапа — проект. Мы не можем строить второй этаж, если нет первого или хотя бы его несущих конструкций. Мы не можем приступить к моделированию, пока у на нет проекта.
Не всегда Event Storming нужно делать прям до самого третьего этапа. Например, работа бизнес-аналитиков заканчивается уже на первом.
На втором этапе бизнес может выдохнуть. Дальше работают технари. Разделяя процесс на этапы мы можем планировать время, которое нужно провести с доменными экспертами и понимаем, когда от них можно отстать.

Выявление и проектирование процессов или Big Picture

Отражение общей картины процессов тоже можно разделить. Вот подэтапы :

Обнаруживаем все события.
Выстраиваем оранжевые Event от более ранних к более поздним.
Валидируем методом прямого чтения цепочки оранжевых стикеров (слева направо).
Верифицируем методом обратного чтения цепочки (справа налево).
Определяемся с тем, какие процессы будут происходить автоматически, а где потребуется влияние человека.

Параллельно мы делаем несколько других важных вещей:

оставляем комментарии;
определяем термины и закладываем основу DDD;
обнаруживаем ключевые события, после которых один процесс переходит в другой (они же – точки слабой связности).

Все это происходит как бы само собой пока мы обсуждаем событийность. Важно не забывать фиксировать. Для этого предусмотрены специальные стикеры. А точки слабой связности маркируются вертикальной чертой.

Этот этап может быть болезненным. Здесь много поводов для споров и конфликтов. Становятся очевидны проблемы, на которые раньше удавалось закрывать глаза. А заказчики внезапно могут понять, что вообще не туда копают и хотели бы иного. Зато Big Picture – хороший способ синхронизироваться и договориться об общих смыслах. Здесь я рассказывала об одном из таких случаев.

Когда мы собрали и построили все оранжевые стикеры, то это как будто мы держим всех змей за хвост. Теперь нужно зафиксировать головы. Я пишу этот текст в Сочельник накануне 2025 года змеи и не смогла удержаться от аналогии.

Если посмотреть на Флоу, то можно заметить, что оранжевый стикер его закрывает. А открывает – светлый прямоугольник с Actor. Человек – всему голова. Но некоторые вещи он поручает своим электронным помощникам. Событие “Пользователь зашел на сайт” – это про человека. Но попользоваться сайтом может и робот и это не всегда выгодно. Необходимо событие: “Проверка на бота пройдена”. Если эту работу будет делать человек, то посетителей на сайте может стать так мало, что исчезнет смысл его существования.

Как мы будем решать этот вопрос? Разработаем ли свою систему проверки? Будет ли она работать только на сайте или это универсальная система для веба и мобилок? А что если купить готовое решение? Все эти вопросы не решить без бизнеса. Поэтому принято относить слой карточек Actor и External System к первой стадии Event Storming – Big Picture

Process Modeling: как строится модель системы в Event Storming

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

Вопрос, который мы теперь себе задаем: “На что опирается человек, чтобы принять решение, которое приведет нас к желаемому событию? На что он смотрит? Что считывает?” Если “пользователь зашел на сайт”, то можно предположить что до этого он смотрел в окно браузера. Если “клиент подписал договор”, то на зеленой карточке у нас будет написано “договор”. Если “проверка на бота пройдена”, то вместо актора у нас внешняя система и смотрела она, скорее всего, в какой-то брокер сообщений. Но для них еще рано.

Зеленые карточки Read Model есть только там, где светлые стикеры Actor и размещаются сразу за ними. Возможно бывают другие случаи, но я с ними не встречалась.

Команда (Command) – более распространенная сущность. В отличие от события, которое пишется в форме прошедшего времени, команда направлена в будущее. Наверное можно сказать, что это аналог задач в нотации BPMN. Что нужно сделать, чтобы достичь желаемого события?

Если “пользователь зашел на сайт”, то Actor-пользователь дал браузеру команду “зайти на сайт”. Если проверка на бота не пройдена, то внешняя система дала тому же браузеру команду “заблокировать и отобразить ошибку”. А если пройдена, то другую — “пропустить и отрисовать страницу сайта”.

“Если” – это стикер с названием Policy. На нем мы записываем все бизнес-правило целиком. Для экономии места можно пользоваться краткими формулировками. Например: “Пропускать только те запросы, которые определены как поведение человека”.

И это всё. Дальше трюк для избранных — Aggregate.

Software Design или когда пора дизайнить систему?

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

Стикеры агрегатов принято относить к третьей стадии Event Storming. Вокруг этой сущности мы обычно выстраиваем модули будущей системы, ориентируясь на ключевые события, свидетельствующие о переходе из процесса в процесс. То, как это происходит – тема отдельной статьи. Здесь я попробую объяснить что такое Агрегат.

На что воздействует человек или система, отправляя команду-задачу на достижение желаемого события? Вот этот объект воздействия и исполнитель команды – агрегат. Если пользователь положил несколько товаров в корзину, то объект воздействия – корзина. Если пользователь решил оплатить все свои покупки, то агрегат – всё ещё корзина. Если пользователь проверяет когда будут доставлены его покупки, то агрегатом будет, скорее всего, – заказ.

Граница агрегата – это граница транзакции. Товар может быть агрегатом. Корзина с несколькими товарами тоже может быть агрегатом. Это некая программная сущность, которая может содержать (агрегировать) несколько объектов и\или свойств, но информацию обо всех этих объектах-свойствах мы должны передавать одновременно, чтобы не нарушить целостности и исключить риск потери данных.

Мне думается, что агрегатами могут быть простые односоставные программные сущности. Например, если мы используем Event Storming для предварительного технического анализа поставленной программисту задачи.

На Aggregate стикеры заканчиваются. Дальнейший System Design делают с применением обычных иконок, обозначающих базы данных, брокеры и прочие кафки. Здесь нам есть что показать бизнесу (построенная модель системы) и есть о чем его спросить:

про максимальное количество пользователей, использующих систему одновременно,
про уровень надежности, который мы хотим и можем себе позволить…

После всего огромного пласта работы, который мы проделали ранее, ответы на классические вопросы System Design перестанут быть фантазией. На руках будут факты. Так легче и архитекторам, и бизнесу. Есть на что опереться.

Видеоматериалы

В продолжении темы System Design – видеозапись архитектурной каты где проектировали систему поддержки клиентов через чат. Просто посмотрите что получилось у команды, где был Сергей Баранов и что у других команд. Возможно это поможет вам понять нужен ли Event Storming перед дизайном системы.
В этом двухчасовом видео, на которое я ссылалась в начале статьи, Сергей Баранов рассказывает про то, что такое Event Storming и сразу показывает как его делать. Все достаточно наглядно. Плюс несколько любопытных случаев из практики.
В пятом сезоне Podlodka Java Crew был доклад Кирилла Ветчинкина “Проектируем Event Driven-систему с помощью DDD и Event Storming”. Купить записи Java Crew #5 можно всего за 3000. Там много полезного, особенно про Debezium от Евгения Ефименко.
Доклад Кирилла наглядно показывает как делать Шторминг от оранжевой карточки до систем-дизайна. Это краткая версия его курса про микросервисную архитектуру, который является лучшим способом научиться делать Event Storming из всех известных мне на данный момент. Если вдруг вы знаете где в свободном доступе есть доклады Кирилла про Шторминг, напишите мне, пожалуйста.

Очень кратко про то, как делать Event Storming

Находим и выписываем все события, происходящие в процессе. Оформляем в форме прошедшего времени.
Расставляем события по линии времени от более ранних к более поздним.
Проверяем цепочку методом прямого чтения и добавляем пропущенные события.
Проверяем события методом обратного чтения и обнаруживаем, что не все учли.
Если процессы начинают ветвится, то там, где у нас исключающая, а не дополняющая ветка, добавляем стикер бизнес-правила (Policy).
Прописываем инициаторов событий – человека в определенной роли или внешнюю систему.
Добавляем View (Read Model). Как правило, это экранная форма.
Добавляем команды (задачи).
Прописываем агрегаты.
Дизайним систему.

Всю дорогу помним про комментарии и то, как важно договориться по поводу терминов.

Успешного системостроения!

Опубликовано 27 декабря 2024