Event Storming — методика, которая экономит месяцы на анализе
Разбираем, что такое Event Storming и как он помогает проектировать микросервисы.
Что такое Event Storming и откуда он взялся
Event Storming — это визуальная фасилитационная техника для исследования предметной области, придуманная Альберто Брандолини в 2012 году.
В её основе — принципы Domain-Driven Design (DDD) и идея, что правильная архитектура начинается с понимания того, как работает бизнес.
Главная особенность — мы не пишем диаграммы UML и не начинаем с базы данных. Мы моделируем поток значимых событий в жизни системы, которые важны для бизнеса, а не только для разработчиков.
В её основе — принципы Domain-Driven Design (DDD) и идея, что правильная архитектура начинается с понимания того, как работает бизнес.
Главная особенность — мы не пишем диаграммы UML и не начинаем с базы данных. Мы моделируем поток значимых событий в жизни системы, которые важны для бизнеса, а не только для разработчиков.
Зачем это нужно в контексте микросервисов
Микросервисы — это не про “разделить на куски код”, а про правильно выделить границы сервисов вокруг бизнес-контекстов.
Event Storming помогает:
Если пропустить этот этап — велика вероятность, что микросервисы получатся “по слоям технологий” (API, DB, сервисы) и быстро превратятся в распределённый монолит.
Event Storming помогает:
- Понять, где проходят границы доменов
- Определить Bounded Context для DDD
- Выявить потенциальные интеграции между сервисами
- Найти узкие места и риски в процессах до того, как написан первый код
Если пропустить этот этап — велика вероятность, что микросервисы получатся “по слоям технологий” (API, DB, сервисы) и быстро превратятся в распределённый монолит.
Распределённый монолит — это распределенная система, которая формально разделена на несколько сервисов и развёрнута в распределённой среде (например, как микросервисы), но при этом сохраняет характеристики и проблемы монолита.
По сути, распределённый монолит — это монолит, разрезанный по техническим признакам, но не по архитектурным границам. Он сочетает в себе сложность распределённой системы и недостатки монолита, не давая преимуществ ни одного подхода.
По сути, распределённый монолит — это монолит, разрезанный по техническим признакам, но не по архитектурным границам. Он сочетает в себе сложность распределённой системы и недостатки монолита, не давая преимуществ ни одного подхода.
Основной принцип декомпозиции
Decompose by Subdomain — это архитектурный паттерн из Domain-Driven Design, который помогает разделить систему на микросервисы по смыслу, а не по технологиям.
Вместо того чтобы делить сервисы по слоям (API сервис, БД сервис, Auth сервис), мы выделяем их по субдоменам предметной области.
Субдомен — это логически обособленный участок бизнеса со своими задачами, терминами и правилами.
Почему это важно для микросервисов:
Связь с Event Storming
На шаге декомпозиции событий в Event Storming мы группируем их в смысловые блоки.
Каждый блок и есть потенциальный Bounded Context, который в микросервисной архитектуре станет отдельным сервисом.
Если вы делите систему без учёта субдоменов, велика вероятность создать распределённый монолит — набор сервисов, которые технически разнесены, но логически зависят друг от друга.
Вместо того чтобы делить сервисы по слоям (API сервис, БД сервис, Auth сервис), мы выделяем их по субдоменам предметной области.
Субдомен — это логически обособленный участок бизнеса со своими задачами, терминами и правилами.
Почему это важно для микросервисов:
- Ясные границы — каждый сервис отвечает за свой кусок бизнеса.
- Слабая связанность — изменения внутри одного сервиса не ломают остальные.
- Оптимизация команды — каждая команда отвечает за свой субдомен целиком.
- Простота масштабирования — можно усиливать только нужные части системы.
Связь с Event Storming
На шаге декомпозиции событий в Event Storming мы группируем их в смысловые блоки.
Каждый блок и есть потенциальный Bounded Context, который в микросервисной архитектуре станет отдельным сервисом.
Если вы делите систему без учёта субдоменов, велика вероятность создать распределённый монолит — набор сервисов, которые технически разнесены, но логически зависят друг от друга.
Предметная область (Domain) — это совокупность бизнес-понятий, ролей и процессов, с которыми работает система. Например, в e-commerce это каталог, корзина, доставка, оплата и т.д.
Когда архитектура строится вокруг технических решений (Kafka, Kubernetes, Istio), но не опирается на модель предметной области, возникают проблемы: дублирование логики, расплывчатые границы, трудности с развитием.
Здесь на помощь приходит паттерн Decompose by Subdomain. Он предлагает строить микросервисы не по техническим слоям, а по смысловым границам — поддоменам. Каждый сервис должен обслуживать один поддомен и владеть своей логикой и данными.
Когда архитектура строится вокруг технических решений (Kafka, Kubernetes, Istio), но не опирается на модель предметной области, возникают проблемы: дублирование логики, расплывчатые границы, трудности с развитием.
Здесь на помощь приходит паттерн Decompose by Subdomain. Он предлагает строить микросервисы не по техническим слоям, а по смысловым границам — поддоменам. Каждый сервис должен обслуживать один поддомен и владеть своей логикой и данными.
Обзор нотации Event Storming
В Event Storming каждая карточка на доске имеет свой цвет и смысл. Ниже — классическая расцветка и назначение.
Цвет карточки | Что обозначает | Пояснение |
Оранжевый | Доменное событие (Domain Event) | Значимое событие в бизнесе, которое уже произошло и зафиксировано в прошедшем времени. Пример: Заказ создан, Оплата получена. |
Малиновый (иногда розовый) | Внешняя система (External System) | Участники или системы, с которыми взаимодействует домен. Пример: платёжный сервис, CRM. |
Синий | Команда (Command) | Действие пользователя или системы, которое приводит к событию. Пример: Оформить заказ. |
Темно желтый | Агрегат (Aggregate) | Модель, которая хранит состояние и обрабатывает команды. |
Красный | Проблема (Hot Spot) | Место, где что-то непонятно, может сломаться или вызывает вопросы. |
Бледно желтый | Пользователь (Actor) | Кто инициирует событие или действие. |
Фиолетовый | Политика (Policy) | Правило реакции на доменное событие. |
Этапы проведения Event Storming
1. Подготовка
2. Генерация событий (Big Picture)
3. Идентификация команд, ролей и систем
4. Поиск проблем и узких мест
5. Декомпозиция по субдоменам
6. Уточнение и детализация (Process Level)
- Определите цель сессии: исследование всей предметной области или конкретного процесса.
- Подготовьте стену (реальную или виртуальную в Miro, Mural, FigJam).
- Соберите всех ключевых участников: разработчиков, аналитиков, тестировщиков, представителей бизнеса.
2. Генерация событий (Big Picture)
- Участники выписывают все значимые события в прошедшем времени.
- События клеятся в хронологическом порядке.
- Здесь мы получаем большую картину.
3. Идентификация команд, ролей и систем
- Для каждого события задаём вопрос: “Что вызвало это событие?” — это команда (жёлтая карточка).
- Фиксируем, кто или что её вызвал (зелёная/голубая карточка).
4. Поиск проблем и узких мест
- Любая неясность, риск или блокер отмечается розовой карточкой.
5. Декомпозиция по субдоменам
- События группируются в логические кластеры — это будущие Bounded Contexts.
- Здесь подключается паттерн Decompose by Subdomain.
6. Уточнение и детализация (Process Level)
- Если нужно, прорабатываем конкретные процессы глубже: добавляем агрегаты, внешние события, условия.
Выгоды
- Вся команда говорит на одном языке — нет “перевода” между бизнесом и разработкой.
- Ошибки проектирования видны заранее — вы увидите нестыковки и узкие места до кода.
- Быстрое вовлечение новых участников — визуальная модель проще длинных документов.
- Основа для архитектуры микросервисов — границы сервисов получаются из реальных процессов, а не “по таблицам в базе”.
Есть ли подводные камни?
Да — и они часто приводят к тому, что Event Storming превращается в “ещё один воркшоп без пользы”.
Типичные ошибки:
Типичные ошибки:
- Пригласили только разработчиков, без бизнеса
- Пытались “сразу красиво”, вместо потока идей
- Перепрыгнули в обсуждение технологий, не проработав предметку
Хотите освоить Event Storming без проб и ошибок?
Мы используем Event Storming на курсе "Микросервисная архитектура и Event Storming" как ключевой инструмент для проектирования микросервисов и DDD. Вы пройдёте весь путь от хаотичной информации о системе к чёткой архитектурной схеме и поймёте, где должны быть границы сервисов.
👉 Посмотреть программу курса
👉 Посмотреть программу курса
