Ограниченный контекст (англ. Bounded Context) – одна из важный концепций предметно-ориентированного проектирования (сокращ. на англ. DDD), хотя её реализация может быть чрезвычайно сложной. Она может стать техническим решением для хорошего моделирования предметной области.
Ограниченный контекст определяет область применения каждой модели и обеспечивает согласованность модели предметной области в каждом ограниченном контексте.
В своей книге Вон Вернон писал о том, что ограниченный контекст – это прежде всего лингвистическое разграничение. То есть термины и определения могут означать разные вещи, исходя из контекста, где они применяются.
Это разграничение относится к единому языку, который также является ещё одним главным элементом в DDD.
Особенности ограниченного контекста
- Каждый контекст может иметь свой собственный архитектурный подход (уровни приложений, постоянство, инфраструктура и т.д.).
- У всякого ограниченного контекста может быть свой собственный способ сохранения. Например, реляционный, сохранение в памяти или кэше и тому подобное.
- Любой ограниченный контекст имеет свой единый язык.
- Архитектура контекста не обязательно должна быть в шаблоне модели предметной области, она может использовать и трехуровневую модель и реализовать CQRS, Event Sourcing и т. д.
- Ограниченный контекст может разрабатываться разными группами разработчиков. Не обязательно только одной команде знать реализацию всех контекстов, наоборот, из соображений безопасности источник ограниченного контекста может быть ограничен конкретной командой.
- Ограниченные контексты могут взаимодействовать друг с другом несколькими способами.
Контекстная карта
Между командами будут отношения и взаимодействия, которые будут неизбежно проявляться в соответствующем ограниченном контексте. Контекстная карта – общий тип, представляющий отношения между разными командами. Карта контекста содержит несколько шаблонов, позволяющих представить взаимоотношения между ограниченным контекстом:
Общее ядро
От этого типа контекста зависят несколько ограниченных контекстов. Его нельзя изменить, не проконсультировавшись со всеми группами разработчиков, которые от него зависят.
Клиент/разработчик
Нижестоящая команда выступает в качестве клиента для вышестоящей команды (разработчика). Контексты клиента зависят от контекста разработчика. Обе стороны согласовывают требования, а затем вышестоящая команда завершает построение и разработку модели и передаёт её другой команде для дальнейшего использования. Происходит совместная отладка и тестирование. Эта модель основана на дружеских отношениях и поддержках команд.
Конформист
Это сценарий, в котором клиенты и разработчики не согласны друг с другом. Тем самым заказчик вынужден использовать в своём бизнесе то, что предоставил разработчик, даже если это не соответствует потребностям. Клиент должен принять этот факт и смириться с ним.
Партнер
В данном случае две команды зависят от контекста обеих сторон. Им необходимо прилагать усилия для моделирования проекта, чтобы помочь друг другу.
Защита от коррупции
В этом шаблоне клиенты разрабатывают дополнительный уровень защиты против коррупции, чтобы уменьшить влияние разработчиков. Это типичная ситуация, когда модель вышестоящей команды не является дружественной и не подходит для нижестоящей, но они должны полагаться на эту модель.
Открытая служба хоста (Open Host Service)
В этом случае предлагаются специальные услуги, которые может использовать каждый. То есть, команда может предоставить доступ к группе сервисов другим командам. Это особенно полезно, когда необходима интеграция со множеством других систем и когда реализация этих интеграций слишком трудоемка.
Отдельные пути
Когда взаимосвязь двух команд не обязательна. Они могут развиваться и моделироваться независимо друг от друга.
Концепцию ограниченного контекста необходимо применять для разграничения поведения домена на основе его намерений, давая ясное понимание того, что нужно развивать независимо, а что использовать совместно.