Определение Bounded Context
В Domain-Driven Design Bounded Context задаёт область, в которой одна модель остаётся валидной. Внутри границы команда разделяет один словарь и один набор бизнес-решений. На границе интеграция становится явной: события, API и слои перевода заменяют общие изменяемые объекты.
Поисковый запрос «Bounded Context» обычно означает один из трёх вопросов: что означает термин, как провести границу и чем она отличается от микросервиса. Ответ начинается с языка и ответственности, а не с контейнеров или репозиториев.
- Единый язык внутри границы
- Понятный владелец решений и инвариантов
- Явные контракты между Bounded Contexts
- Перевод вместо универсального доменного объекта
Как определить Bounded Context
Ищите изменения в языке, владельцах решений, бизнес-правилах, жизненном цикле, источнике истины и темпе изменений. Граница следует за смыслом и ответственностью, а не за таблицами, экранами или способом развёртывания.
- Один термин имеет разные определения
- Разные команды или функции бизнеса принимают решения
- Отличаются инварианты и жизненный цикл
- На границе требуется перевод данных
Context Map и отношения между Bounded Contexts
Context Map фиксирует Customer/Supplier, Open Host Service, Published Language и Anti-Corruption Layer. Названный тип отношения делает интеграцию и организационные зависимости предметом архитектурного обсуждения.
Частая ошибка
Микросервис не становится ограниченным контекстом автоматически. Один контекст может состоять из нескольких сервисов, а один сервис может случайно смешивать несколько моделей. Начинайте с языка и ответственности.
Границы определяются смыслом, а не развёртыванием
Ограниченный контекст определяют через изучение решений и языка предметной области. Важно понять, кто владеет бизнес-возможностью, какие правила должны применяться вместе, где находится источник истины и какие понятия изменяются совместно. Контекст может быть одним сервисом, несколькими сервисами или модулем монолита. Способ развёртывания — следствие проектирования, а не определение границы.
Полезный тест: спросить, могут ли две команды использовать одно слово, принимая разные решения. Если Order, Customer или Account имеют разные жизненные циклы и критерии успеха, общий объект обычно скрывает проблему интеграции, а не решает её.
- Владелец бизнес-решений и возможностей
- Устойчивый язык внутри границы
- Понятный источник истины для важных фактов
- Явный перевод на границе
Как строить Context Map
Context Map фиксирует отношения между контекстами. Сначала назовите upstream- и downstream-стороны, затем укажите, что передаётся через границу: команды, события, запросы или опубликованный язык. Отдельно зафиксируйте, кто управляет контрактом и что произойдёт при его изменении.
Такая карта делает видимыми техническую и организационную связанность. Customer/Supplier показывает зависимость одной команды от другой. Anti-Corruption Layer означает, что downstream-модель намеренно защищена от терминологии upstream. Это архитектурные решения, а не просто стрелки на диаграмме.
Паттерны интеграции контекстов
Open Host Service подходит, когда контекст предоставляет стабильный интерфейс нескольким потребителям. Published Language — когда общий контракт заслуживает отдельного версионируемого формата. Conformist допустим, если принять модель upstream действительно приемлемо. Если важна независимость, входные данные нужно переводить в собственные понятия принимающего контекста.
Предпочитайте контракты бизнес-уровня и не публикуйте внутреннюю схему хранения. Контекст должен открывать факты и возможности, которые он готов поддерживать, сохраняя агрегаты, таблицы и детали реализации внутри.
Вопросы для проверки границы
Граница готова к обсуждению, когда команда может объяснить, за что контекст отвечает, за что не отвечает и как другой контекст получает информацию, не обращаясь к его внутренностям.
- Какие бизнес-решения принадлежат этому контексту?
- Какие термины имеют здесь точное определение?
- Какие инварианты защищаются локально?
- Какие события или API являются публичным контрактом?
- Как выполняется перевод и обрабатываются ошибки?
FAQ по Bounded Context
Что такое Bounded Context (ограниченный контекст) в DDD?
Bounded Context — явная граница в Domain-Driven Design, внутри которой доменная модель и единый язык остаются согласованными. Внутри этой границы термины вроде Order или Customer имеют один точный смысл. За её пределами те же слова могут означать другое и требуют перевода.
Как определить ограниченный контекст?
Ищите изменения в языке, владельцах решений, бизнес-правилах, жизненном цикле, источнике истины и темпе изменений. Bounded Context следует за смыслом и ответственностью. Его не определяют схема базы, экран интерфейса или способ развёртывания.
Bounded Context и микросервис — это одно и то же?
Нет. Микросервис — это способ развёртывания. Один Bounded Context может быть одним сервисом, несколькими сервисами или модулем монолита. Один сервис также может случайно смешивать несколько конфликтующих моделей. Начинайте с языка и ответственности, затем решайте, как деплоить.
Что такое Context Map в Domain-Driven Design?
Context Map показывает, как взаимодействуют Bounded Contexts. На ней фиксируют upstream- и downstream-стороны и паттерны вроде Customer/Supplier, Open Host Service, Published Language, Conformist и Anti-Corruption Layer. Карта делает видимыми и технические контракты, и зависимости между командами.
Какой пример Bounded Context можно привести?
В интернет-магазине типичные Bounded Contexts — Ordering, Catalog, Payments, Inventory и Shipping. Customer в Sales, Support и Billing может относиться к одному человеку, но каждый ограниченный контекст хранит свою модель, потому что решения, правила и жизненный цикл различаются.
DDDesigner
Пример: Customer в Sales, Support и Billing
В Sales Customer — потенциальный покупатель, владелец сделки и коммерческие отношения. В Support это инициатор обращения с тикетами, историей обслуживания и правами доступа. В Billing Customer — юридическое лицо, получающее счета и несущее платёжные обязательства. Контексты могут обмениваться стабильным идентификатором и выбранными фактами, но не должны использовать один универсальный объект Customer. Context Map может показать, как Sales публикует событие о квалифицированном клиенте, Support подписывается на него, а Billing сохраняет собственную модель юридического клиента.
Начать бесплатно