EVENT STORMING #3 Preconditions. Ограниченный контекст.

Преодолев лень, продолжим. Осталось немного напитаться знаниями и уже перейти к практике.

В этой статье речь пойдет о сущности, представляющей одну из основных ценностей Event Storming (ES) — ограниченных контекстах. Фактически, ограниченный контекст позволяет конкретизировать границы будущих информационных систем и/или сервисов и в дальнейшем определить их взаимоотношения.

Что такое ограниченный контекст и зачем он нужен?

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

Домен - область бизнес проблем, ограниченный контекст - область решений.

Домен vs Ограниченный контекст

• Домен — область бизнес-проблем.
• Ограниченный контекст — область решений, в которой формируется модель, отвечающая за реализацию части бизнес-функций.

Ограниченный контекст ограничен:

1. Конкретной ответственностью в аспекте реализации бизнес-функций.
2. Границами представлений модели, которые могут отличаться в разных контекстах по структуре, терминологии и принципам моделирования.

Как выделять ограниченные контексты?

Жестких правил нет, но можно ориентироваться на несколько подходов:

• Критерии связанности контекстов (сильные зависимости между элементами модели могут указывать на один контекст).
• Критерии организационной структуры команд (например, контексты могут соответствовать командам, отвечающим за разные бизнес-направления).
• Правило Владислава Хононова: «Декомпозируйте до того момента, пока это приносит пользу вашему решению».

Дополнительно:

• Если две команды вынуждены синхронизировать свои бэклоги на 100500%, то разделение контекстов не принесет пользы.

Составляющие ограниченного контекста

1. Общий язык (Ubiquitous Language)

Ограниченный контекст описывается поддоменом общего языка. Термины, определения и их значения обусловлены предметной областью и моделью. Они могут отличаться в разных контекстах, но при этом коррелировать между собой.

2. Модель

Модель:

• Описывает бизнес-правила, решения и политики, специфичные для конкретного ограниченного контекста.
• Должна точно отражать язык контекста.
• Формируется под конкретный контекст (важнее учитывать требования бизнеса, чем следовать общим правилам моделирования).

При Event Storming доменные события должны отражать бизнес-процессы максимально точно. Если одно и то же событие происходит в разных контекстах, то фактически это разные события.

3. Инвариант

Инвариант — это бизнес-правило или ограничение, которое должно оставаться неизменным в пределах контекста.

Пример бизнес-инварианта

В агрегате «Банковский счет» инвариантом является правило: баланс не может быть отрицательным. Это ограничение соблюдается независимо от количества транзакций.

Зачем бизнес-инварианты нужны для ограниченного контекста?

1. Гарантия целостности данных — контекст должен обеспечивать согласованность своей области.
2. Автономность — контекст не должен зависеть от того, как другие контексты управляют своими данными.
3. Упрощение управления сложностью — у каждого контекста есть четкие границы, внутри которых он поддерживает целостность.
4. Основной элемент агрегатов — инварианты реализуются через Aggregate Root.

Без инвариантов ограниченный контекст теряет смысловую границу и становится уязвимым для ошибок.

Связь между Event Storming и ограниченным контекстом

Event Storming — это не только метод визуализации событий, но и инструмент для выявления ограниченных контекстов. В процессе Event Storming:

1. Выявляются бизнес-события, что помогает определить ключевые процессы и их границы.
2. Формируются модели взаимодействия — выявляются роли, связи и зоны ответственности.
3. Разделяются доменные области — это помогает определить, какие модели и термины принадлежат конкретному контексту.
4. Обнаруживаются интеграционные точки между контекстами, что важно для построения архитектуры системы.

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

Карта контекстов (Context Map)

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

Цель Event Storming — создать карту контекстов, определить границы контекстов и типы их связей.

Какие бывают связи между контекстами?

Каждый способ интеграции контекстов выбирается исходя из зависимостей и требований к изменяемости системы. Основные паттерны взаимодействия:

1. Customer-Supplier — один контекст (Supplier) предоставляет данные, другой (Customer) использует.
2. Conformist — контекст полностью принимает модель другого.
3. Shared Kernel — два контекста используют общую модель.
4. Anti-Corruption Layer (ACL) — адаптация для защиты своей модели от чужой.
5. Open Host Service — единый API для всех потребителей.
6. Separate Ways — контексты развиваются независимо.

На этом мы остановимся, кажется, что знаний для практики Event Storming должно хватить. В следующей статье как раз и начнем описывать методику организации ES.