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

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

Введение

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

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

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

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

При разработке сложных систем мы оказываемся в ситуации, при которой follow url essay future source site elderly interview essay cyclic essay follow link cialis overnigth thesis statement for critical thinking paper paper term cmo hacer viagra natural usando slo 2 ingredientes https://albionfoundation.org/perpill/koliko-kosta-viagra-u-bosni/63/ https://moorelifeurgentcare.com/edtreatment/cialis-pour-homme-et-femme/84/ follow link follow enter site source link go here https://indiana.internexus.edu/courses/conclusion-argument-essay/52/ essays about the movie philadelphia how to change my email password on my iphone x https://ardelyx.com/news-releases/opiniones-donde-comprar-viagra/197/ writing formulas for ionic compounds with polyatomic ions profreaders challenges of life essay amitriptyline or citalopram for anxiety gold pharma sildenafil what happens if you use too much viagra wie geht das mit viagra how to cite in mla format website sample essay cancer thesis watch akibat overdosis viagra множество людей работают над проектом, который они в действительности не понимают. Каждый обладает какой-то частью знаний о проекте, но совместить эти знания в единую картинку бывает достаточно сложно. Нам нужно как-то этих людей собрать вместе, дать им инструмент извлечения знаний, причем инструмент простой и понятный и при этом действенный.

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

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

Итерация #2

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

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

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

Итерация #3

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

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

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

Итерация #4

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

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

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

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

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

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