Event Storming
Метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему.
Зачем
- Быстро собрать унифицированные требования
- Описание бизнес-процесса
- Поиск зон ответственности (акторов, заинтересованных лиц)
- Создание непротиворечивой терминологии
- Помогает быстро получить стратегический дизайн, определив границы, в рамках которых технические решения можно принимать автономно
- За счет автономности значительно упрощается управление техническим долгом
- Если преднамеренно не нарушать границы на уровне реализации, то зависимости не появятся
- Общее понимание бизнеса
- Формирование границ доменов
- снижает риски декомпозиции на сервисы и реализации распределенного монолита
- В монолите проще провести рефакторинг
- микросервисы как распределенный монолит - дорого рефакторить из за интеграций.
- Если преднамеренно не нарушать границы на уровне реализации, то зависимости не появятся
- Нет зависимостей на уровне сущностей
- снижает риски декомпозиции на сервисы и реализации распределенного монолита
- Появляется возможность эволюционного развития к целевому видению
- Поиск ключевых сущностей
- Моделирование реактивной архитектуры
- Позволяет получить разный уровень детализации
Примеры
План проведения
- можете ли вы разделить область знаний на более мелкие бизнес-процессы, которые вы моделируете один за другим в нескольких циклах Event Storming.
- События (факты) в прошедшем времени
- вопросы для уточнения событий
- Hot Spots - вопросы на подумать
- Основные события выступают как главы в общем повествовании, предоставляя порядок и структуру общего контекста. Эти «главы» естественная граница для поддоменов и/или процессов. Признаки выделения основных событий: - Временные границы - начало или окончание процесса Начало или окончание пути пользователя - Лингвистические границы - изменение названия сущности (Объявление > Вакансия) - Роли и ответственности - Передача сущности от одного человека другому - Начало или окончание процесса с точки зрения роли - Начало или окончания пути пользователя с точки зрения роли - Точки принятия решений - Критические события
- акторы (роли) -> команды
- единый язык (термины)
- команды
- команды -> агрегаты
- команды -> внешняя система
- решение пользователя в ответ на информацию в Модели Чтения
- Запрос на выполнение действия
- Действие еще не выполнено и может быть отменено
- Формулируется в будущем времени
- агрегаты -> события
- внешняя система -> события
- события -> бизнес правила
- события -> модель чтения
- Границы моделей данных
- ограниченные контексты DDD -> микросервисы\модульный монолит