Ограниченный контекст (англ. Bounded Context) – одна из важный концепций предметно-ориентированного проектирования (сокращ. на англ. DDD), хотя её реализация может быть чрезвычайно сложной. Она может стать техническим решением для хорошего моделирования предметной области.

Ограниченный контекст определяет область применения каждой модели и обеспечивает согласованность модели предметной области в каждом ограниченном контексте.

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

Это разграничение относится к единому языку, который также является ещё одним главным элементом в DDD.

Особенности ограниченного контекста

• Каждый контекст может иметь свой собственный архитектурный подход (уровни приложений, постоянство, инфраструктура и т.д.).
• У всякого ограниченного контекста может быть свой собственный способ сохранения. Например, реляционный, сохранение в памяти или кэше и тому подобное.
• Любой ограниченный контекст имеет свой единый язык.
• Архитектура контекста не обязательно должна быть в шаблоне модели предметной области, она может использовать и трехуровневую модель и реализовать CQRS, Event Sourcing и т. д.
• Ограниченный контекст может разрабатываться разными группами разработчиков. Не обязательно только одной команде знать реализацию всех контекстов, наоборот, из соображений безопасности источник ограниченного контекста может быть ограничен конкретной командой.
• Ограниченные контексты могут взаимодействовать друг с другом несколькими способами.

Контекстная карта

Между командами будут отношения и взаимодействия, которые будут неизбежно проявляться в соответствующем ограниченном контексте. Контекстная карта – общий тип, представляющий отношения между разными командами. Карта контекста содержит несколько шаблонов, позволяющих представить взаимоотношения между ограниченным контекстом:

Общее ядро

От этого типа контекста зависят несколько ограниченных контекстов. Его нельзя изменить, не проконсультировавшись со всеми группами разработчиков, которые от него зависят.

Клиент/разработчик

Нижестоящая команда выступает в качестве клиента для вышестоящей команды (разработчика). Контексты клиента зависят от контекста разработчика. Обе стороны согласовывают требования, а затем вышестоящая команда завершает построение и разработку модели и передаёт её другой команде для дальнейшего использования. Происходит совместная отладка и тестирование. Эта модель основана на дружеских отношениях и поддержках команд.

Конформист

Это сценарий, в котором клиенты и разработчики не согласны друг с другом. Тем самым заказчик вынужден использовать в своём бизнесе то, что предоставил разработчик, даже если это не соответствует потребностям. Клиент должен принять этот факт и смириться с ним.

Партнер

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

Защита от коррупции

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

Открытая служба хоста (Open Host Service)

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

Отдельные пути

Когда взаимосвязь двух команд не обязательна. Они могут развиваться и моделироваться независимо друг от друга.

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