🟠 Event Storming: что это и зачем? Связь с DDD 🟠

Одна из главных проблем на старте разработки — разрозненное понимание процессов.


💡 Event Storming — это командная техника "мозгоштурма", которая позволяет:

+ собрать все события бизнес-процесса “от и до”

+ увидеть взаимосвязи между процессами, событиями, данными и системами

+ подготовить основу для построения Bounded Context и Domain Model в DDD.



👉 Как работает Event Storming:

1. Собираем участников: бизнес, аналитиков, разработчиков, архитекторов

2. Выбираем процесс к исследованию

3. Выстраиваем ленту событий на большой доске (Miro, draw io или реальная стена)


👉 Слои модели:

1. События домена — произошедшие факты, в прошедшем времени

2. Команды — действия, которые инициируют события

3. Агрегаты — бизнес-сущности, где хранятся и изменяются данные.

4. Внешние системы

5. Правила



👉 Пример для процесса: “Въезд-выезд на парковке”

🔗 Miro-доска
с примером и теорией


Расклад процессов на доске Miro позволяет:
▫️ увидеть основной сценарий (въезд → стоянка → оплата → выезд)
▫️ учесть альтернативные ветки (не распознан номер, не оплачено вовремя, платёж отклонён)
▫️ проверить полноту требований




📌 Как проводят границы DDD (Bounded Context) после Event Storming

Когда мы делаем Event Storming, у нас получается “лента событий”.

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

И каждая такая группа = ограниченный контекст (Bounded Context).

👉 Примеры группировки также показан в Miro

У каждого контекста DDD свой набор терминов и свои правила, которые не зависят от других зон. Наполнение для контекстов получено из Event Storming.

На стыках контекстов мы передаём события или команды через API или брокер сообщений.

В микросервисной архитектуре каждый контекст можно реализовать отдельным сервисом (или группой сервисов), а в монолите — отдельным модулем.


Разбирайтесь наглядно на примере в Miro! И сохраняйте ссылку на доску себе в закладки 😃


#АрхитектураGA #ParkingGA