Event Storming на практических кейсах

Выступил на митапе сообщества DDDevotion в Райфайзен Банке с докладом про Event Storming. Ниже краткий пересказ по итогам.

Введение

При появлении желания перейти на микросервисную архитектуру у людей появляется множество вопросов. Вот лишь некоторые из них:

  • Понять, как правильно проектировать микросервисы
  • Как расшарить модель данных?
  • Определение границ сервиса
  • Как определить контекст сервиса?
  • Научиться проводить границы контекстов
  • Своя база — дублирование данных?
  • Деление на микросервисы по предметным областям
  • Алгоритм перехода на микросервисы
  • Как не получить распределенный монолит?

И действительно, как правильно проектировать? Однозначного ответа нет и не будет. Если бы он появился, то не на долго, — сразу же появилась бы другая, стремящаяся занять пьедестал! Но есть хорошие практики, которые показали свою состоятельность на практике. Одна из такиз практик:

Event Storming Logo

Какую проблему решаем?

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

Из сложности понимания мы приходим к ситуации, когда требования не полны, противоречивы или попросту неверны. Некоторые пытаются исправить ситуацию с помощью Кафки 🙂 Но правда в том, что ни одна технология не поможет исправить плохих или неверных требований. Совсем плохо, если начинается поиск виноватых. Но чаще всего — никто не виноват. Скорее, нужна техника, которая поможет построить достаточно полную общую модель на основе разрозненных знаний всех вовлеченных в разработку и использование продукта людей.

Основная задача Event Storming: «Формирование общего понимания бизнес-процесса разрабатываемого продукта». Звучит обще и немного не инновационно, зато просто.

Event Storming помогает
  • Понять, какие шаги — в скоупе, а какие — за его пределами
  • Найти вовлеченных в процесс действующих лиц
  • Определить первичный UI или улучшенный UX
  • Выявить неявные зависимости на уровне бизнеса
  • Найти бутылочные горлышки в процессе
  • Выявить пропущенные события в процессе
  • Найти первичные Aggregates

И в целом Event Storming — великолепная практика, облегчающая дальнейшую работу в области Domain Driven Design, проектирования микросервисов и планирования событий в событийных архитектурах.

Что это такое?

Alberto Bandolini, автор метода, дал ему следующее определение:

Определение Event Storming

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

Начнем с того, что Event Storming быстрее и приятнее, чем традиционные методы моделирования процессов. Нет рутины, всё в движении и в бурном, живом обсуждении.

Общий язык

По мере обсуждения формируется общий язык между IT и бизнесом. Важность этого сложно переоценить — это избавляет нас от ТЗ формата «Перевод с языка бизнеса на технический». Почему? Потому что код, дизайн, архитектура могут и должны использовать терминологию бизнеса, они как-бы отражают бизнес.

Здесь есть еще один важный момент — участники начинают улавливать тонкие различия между Сущностями, которые, если посмотреть только на данные, обозначают одно и то же. Так, если мы говорим о конференциях, то сущность Пользователь может уйти вовсе, но появятся сущности Посетитель, Спикер, Волонтер. И это разные сущности в разных контекстах, и даже атрибут «Компания» у каждой сущности может быть свой: выступаю от лица одной компании, пришел на конференцию от лица другой. Хотя на уровне модели данных атрибут может выглядит как один и тот же.

Итеративность

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

Итеративность Event Storming

Итеративность дает нам еще одно премущество: мы можем фокусно отбирать участников каждой сессии в зависимости от конкретных вопросов, требуемых обсуждения.

Связь с DDD

С точки же зрения моделирования Event Storming предоставляет высокоуровневую картинку решения, помещая детали технической реализации в контекст бизнес-процесса, как результат — становится очень эффективной техникой для перехода к DDD.

Элементы Event Storming

Event Storming уже содержит в своей структуре команды, события, слушателей (Listeners, как связку между внешними системами и Policy) и Агрегаты.

Как выглядит результат?

Ниже результат проведения первой итерации Event Storming на 40 человек в отдельном, достаточно большом, домене бизнеса:

Event Storming

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

Event Storming и агрегаты

По факту каждый агрегат в части реализации — это либо отдельный микросервис, либо модуль. Главное здесь то, что мы построили слабосвязанную модель на уровне бизнес-сущностей. Если взять эту модель как стратегический дизайн, то реализация становится тактикой наполнения модели техническими деталями: кодом и данными. В чем смысл? Смысл в том, что соблюдая границы, определенные моделью, мы просто физически не сможем создать зависимости на уровне кода и данных. А как мы знаем, тормозят нас две вещи: зависимости и технический долг. Неплохой способ устранить хотя бы один из факторов торможения 🙂

Структура модели Event Storming

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

Структура Event Storming

Здесь Command — это решение, принятое пользователем как ответ на некоторую информацию, полученную из Read Model и представленную посредством Screen Layout. Command всегда формулируется в будущем времени, например: «Открыть депозит», «Заказать такси». Read Model в таком случае может представлять собой данные со страницы депозитов или карту расположения таксистов.

Actor (фигурка человека) — это тот, кто инициирует команду. Ответить на Command и инициировать Event (событие) — ответственность Системы или Агрегата.

Policy или Procedures — это дополнительные бизнес-правила, которые могут самостоятельно инициировать команды. Например, при заказе такси, Policy может учитывать рейтинг водителя, а Procedure принимать решение о выборе алгоритма расчета стоимости поездки.

В конечном счете, Агрегат, относящиеся к нему команды, события и модель чтения вполне могут представлять микросервис (разумеется, это наше предположение и это далеко не единственный способ четко определить границы сервиса).

Микросервис

Как провести?

Люди

Вам понадобятся люди с вопросами и люди с ответами на эти вопросы.

Люди

Ценность именно во взаимодействии между людьми — пропустишь одного и пропустишь N-1 взаимодействий. Не стоит переживать, если какие-то вопросы останутся без ответов. Итеративная природа метода подразумевает возможность собраться повторно, предварительно проведя небольшое исследование проблемной области.

Место

Потребуется много свободного пространства.

Место

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

Инструменты

Представьте себе много стикеров. Очень много стикеров. И возьмите в 10 раз больше. Лучше пусть останутся, чем прерывать сессию из-за такой мелочи. Помимо этого понадобится рулонная бумага (ее удобнее сворачивать и забирать с собой, чем личты от флипчарта) и маркер каждому участнику.

Проведение

Приведу классический, достаточно эффективный способ проведения, разбитый на итерации

Итерация #1

Цель: выявить максимальное количество событий.

  1. Привести простой пример, например на небольшом магазине или сервисе заказа такси
  2. Рассказать теорию о событиях
    1. Что-то, что произошло в прошлом
    2. Всегда в прошедшем времени («Клиент оплатил товар»)
  3. Практика
    1. Разбиться на пары или тройки и внутри группы выписать все события, происходящие в системе или бизнесе
    2. Поочередно разместить события на временной шкале
    3. Проиграть вслух события вперед и назад
Event Storming - события
Итерация #2

Цель: выявить команды, действующих лиц, внешние системы и модели чтения

  1. Привести простой пример
  2. Рассказать теорию о Командах, Действующих лицах, внешних системах и модели чтения
  3. Практика
    1. Перемешаться, в каждой группе должен быть как минимум один эксперт в предметной области
    2. Сразу на стене размещать Команды, Действующих лиц, внешние системы и модели чтения.
    3. Каждая команда проигрывает процесс остальным. Выявляется еще больше пробелов. Отлавливаем предположения и заполняем пропущенное.
Event Storming - команды

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

Итерация #3

Цель: выявить правила и процедуры. Они заполняют собой пустоты между Command и Event. Можно задавать вопросы вида «Это происходит всегда?» или «Это Событие всегда следует за этой Командой?». 

  1. Привести простой пример
  2. Рассказать теорию о Policy и Procedures
  3. Практика
    1. Размещаем на стене Policy и Procedures
    2. Проигрываем события вперед и назад.
Event Storming - политики

На примере выше Refund Policy — это как раз правило возврата денежных средств. Конкретные детали выявим позже, сейчас для нас главное узнать о том, что такое правило существует.

Итерация #4

Цель: выявить агрегаты.

Первое правило выявления Агрегатов — не говорить слово Агрегат 🙂 Этот термин может запутить, но, конечно, все зависит от начальной подготовки участников.

Агрегат — это своего рода State Machine (конечный автомат) системы. Это то, что принимает команду и решает, реагировать на нее или нет. Можно не вводить термин агрегат, а ввести термин Система. Когда поток событий становится более четким, воспроизводим события еще раз. Если на карточке не существующая (то есть еще не разработанная) Система, можем дать ей какой-нибудь бессмысленное название. Какие-то команды будут относится к этой Системе. Когда проход завершен, вернитесь к именам. Они должны прийти сами собой.

  1. Привести простой пример
  2. Рассказать теорию об Агрегатах
  3. Практика
    1. Попарное выделение агрегатов
    2. Проигрываем события вперед и назад.
Event Storming - агрегаты

Рекомендации

В конце хотелось бы дать ряд рекодментаций, повышающих эффективность сессий:

  • Приводите простые примеры
  • Несмотря на очень простые правила, люди не понимают с первого раз что нужно делать. Правила должны быть у всех на виду. ОЧЕНЬ хорошо видны. Иначе будете бегать и пояснять. Желательно сразу показать, как будет выглядеть конечный результат.
  • Не начинайте моделирование с углов
  • Вначале можно разделить людей, так дело пойдет быстрее. Мы делились по продуктам, несмотря на то, что поток событий был единым.
  • Забудьте роли и контракты, они не должны ограничивать поиск решения
  • Первыми помещают стикеры бизнес-люди, иначе мы быстро скатимся к технической реализации
  • Команды можно положить в бэклог («Заказать такси на определенное время» — чем не элемент бэклога?)
  • Задавайте много вопросов
  • Что произойдет, если что-то пойдет не так, как задумано?
  • Это происходит всегда или иногда?
  • Что должно произойти, чтобы это событие произошло?

Спасибо DDDevotion и лично Жене Пешкову за приглашение и возможность выступить на митапе. Ниже полная презентация, а через какое-то время на хабра-канале Райфайзен Банка

Share