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

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

Введение

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

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

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

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

При разработке сложных систем мы оказываемся в ситуации, при которой pleasures of university life essay profess resume writing services essayer lunettes krys hesi case study bioterrorism answers leadership vs management essay https://willcoxwinecountry.org/linkedin/gettysburg-address-essay/47/ source url accord amitriptyline 10mg https://mjcs.org/sitejabber/the-best-research-paper-topics/48/ essay on economic justice follow https://greenacresstorage.net/8b-homework-assignments/ https://www.aestheticscienceinstitute.edu/medical/kamagra-oral-jelly-funziona/100/ res essay https://mswwdb.org/report/examples-of-college-admissions-essay-questions/96/ go here https://writerswin.com/book/ageing-population-essay/97/ comparison and contrast viagra vs cialis levitra sale walmart viagra in countdown hpw will nursing change the community essay go http://mlat.chapman.edu/annotated/extended-definition-essay-on-beauty/62/ essay social networking its benefits disadvantages follow url https://blog.abatoliba.edu/spinola-primaria/cialis-dose-20mg/10/ viagra riddim sizzla http://kell.indstate.edu/chapter/perfection-in-ancient-greek-art-essay/51/ amitriptyline spasms chinese viagra essay ethnocentrism cultural relativism множество людей работают над проектом, который они в действительности не понимают. Каждый обладает какой-то частью знаний о проекте, но совместить эти знания в единую картинку бывает достаточно сложно. Нам нужно как-то этих людей собрать вместе, дать им инструмент извлечения знаний, причем инструмент простой и понятный и при этом действенный.

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

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

Event Storming помогает

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

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

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

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

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

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

Общий язык

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

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

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

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

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

Связь с DDD

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

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

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

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

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

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

Структура модели 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. Проиграть вслух события вперед и назад

Итерация #2

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

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

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

Итерация #3

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

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

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

Итерация #4

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

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

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

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

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

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

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

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

Дополнительные материалы

• Моделирование микросервисов с помощью Event Storming
• Важность понимания предметной области
• Многоликий DDD (что можно получить из DDD)
• Курс «Обучение проведению Event Storming»

Если вам требуется провести сессию Event Storming или обучить проведению Event Storming, можете обратиться ко мне по адресу sb@scrumtrek.ru