Каким образом отдельные модели в разных ограниченных контекстах уменьшают семантическую связанность системы?
Отдельная модель в каждом ограниченном контексте локализует смысл терминов, правил и инвариантов. Поэтому изменение понятия в одном контексте не требует автоматически менять модель и код во всех остальных; между контекстами остаются явные договорённости и преобразования данных.
Подход возник в рамках предметно-ориентированного проектирования, когда большие системы стали сталкиваться с конфликтующими трактовками одних и тех же бизнес-терминов. Единая модель всей организации обычно разрасталась, смешивала разные правила и делала изменения опасными.
Ограниченный контекст задаёт границу, внутри которой термин имеет согласованный смысл. Например, «клиент» в продажах может означать покупателя, а в службе поддержки — владельца обращения с другой атрибутикой и жизненным циклом.
Если разные части системы используют одну общую предметную модель, любое изменение её сущности затрагивает множество потребителей. Даже когда структура данных формально совместима, изменение смысла поля или правила может незаметно нарушить поведение соседнего компонента.
Попытка устранить расхождения единой моделью создаёт сильную семантическую связанность. Команды начинают согласовывать изменения, релизы синхронизируются, а локальные бизнес-правила проникают в чужие модули.
В каждом ограниченном контексте определяется собственная модель, отражающая его задачи, термины и инварианты. Внешняя система не получает прямого доступа к внутренним объектам; взаимодействие идёт через явно согласованный контракт и преобразование между моделями.
Так локализуются три вида изменений:
Контексты всё равно связаны, но связь становится явной и управляемой. Для интеграции применяют адаптеры, переводчики сообщений или анти-коррупционный слой, который не позволяет внешней модели проникнуть внутрь контекста.
Изоляция не означает, что данные нельзя дублировать. Один контекст может хранить собственное представление нужных ему данных и обновлять его через события или другие интеграционные механизмы. Компромисс состоит в том, что система получает семантическую независимость ценой дублирования, задержки синхронизации и необходимости поддерживать контракты.
Ограниченные контексты не следует создавать для каждой сущности или небольшой функции. Граница оправдана, если внутри неё есть собственные правила, язык, ответственность и характер изменений. Иначе дополнительные преобразования только увеличат сложность.
В интернет-магазине команда продаж использовала общую сущность «Заказ» совместно с командой доставки. Когда продажи добавили статусы оплаты и возврата, логика доставки стала зависеть от полей, которые ей не принадлежали. Изменение одного жизненного цикла требовало согласованного обновления нескольких компонентов.
Рассматривались три варианта. Сохранение общей модели было самым простым в краткосрочной перспективе, но сохраняло связанность. Полное копирование всех данных уменьшало зависимость, однако создавало лишнее дублирование и сложность синхронизации. Прямой обмен внутренними объектами был быстрым, но нарушал границы и раскрывал детали реализации.
Выбрали два контекста: Продажи со своей моделью заказа и Доставка со своей моделью отправления. Между ними оставили контракт с минимально необходимыми данными, а преобразование выполнял интеграционный адаптер. В результате изменения статусов оплаты перестали требовать изменения модели доставки; при этом команда отдельно контролировала задержки обновления и обработку несовместимых сообщений.
Нет. Дублирование может быть осознанной платой за автономность контекстов. Важно, чтобы каждый контекст владел своей копией, ясно понимал источник истины и имел определённую стратегию обновления. Опасно не само дублирование, а неуправляемое расхождение смыслов и отсутствие правил разрешения конфликтов.
Технически можно, но это обычно превращает общую библиотеку в скрытую общую модель. Изменение её классов или правил начинает синхронно затрагивать потребителей, то есть семантическая граница ослабевает. Общими безопаснее делать нейтральные технические компоненты, а доменные модели — только при явном решении создать контролируемое общее ядро с единым владельцем и процедурой изменений.
Нужно искать различия в языке, бизнес-правилах, инвариантах, владельцах и темпе изменений. Если один термин имеет разные определения, изменения должны согласовываться разными командами, а данные требуют разных транзакционных гарантий, это признаки отдельных контекстов. Если же компоненты постоянно изменяются вместе и поддерживают один набор инвариантов, искусственное разделение создаст интеграционные расходы без полезной автономности.