Разработка сложных программных систем требует грамотного структурирования доменной модели. В этом помогает предметно-ориентированное проектирование (Domain-Driven Design, DDD), одним из ключевых понятий которого являются границы контекста (Bounded Context). В этой статье мы разберём, что такое границы контекста, зачем они нужны, и как их правильно определять, а также рассмотрим примеры их применения.

Граница контекста (Bounded Context) — это четко определённая область внутри системы, в которой применяется конкретная модель предметной области. В DDD каждая модель имеет своё предназначение и ограничения, поэтому важно не смешивать различные модели в одном контексте.

Пример: В интернет-магазине есть два разных контекста:

1. Контекст управления товарами (Product Management) — здесь модель описывает характеристики товаров, их категории, цены и наличие на складе.
2. Контекст оформления заказов (Order Processing) — здесь модель фокусируется на заказах, клиентах и оплатах.

Хотя в обоих контекстах фигурирует понятие "товар", его модель в каждом случае будет разной. В контексте управления товарами важны атрибуты (название, описание, цена), а в контексте заказов — количество, статус и стоимость.

1. Определение бизнес-области
Первый шаг — понять, какие ключевые процессы присутствуют в системе. Это можно сделать с помощью интервью с бизнес-экспертами и анализа пользовательских сценариев.
2. Разделение терминологии
Если один и тот же термин (например, "клиент") имеет разное значение в разных частях системы, это сигнал о наличии нескольких контекстов.
3. Выявление команд
В крупных организациях команды часто работают над разными частями системы. Это естественным образом создаёт границы контекста.
4. Анализ зависимостей
Если изменение одной части системы приводит к проблемам в другой, вероятно, границы контекста определены неправильно.

Пример 1: CRM и система биллинга
Допустим, в компании используются две системы: CRM для работы с клиентами и биллинговая система для управления платежами. CRM содержит контактные данные клиентов, их истории взаимодействий, но не должна хранить финансовую информацию. Биллинг, наоборот, не интересуется историей коммуникации, а только платежами. Эти две системы — разные контексты, взаимодействующие через API.

Пример 2: Маркетплейс
В маркетплейсе есть продавцы и покупатели. У продавцов свои бизнес-процессы (добавление товаров, управление ценами), у покупателей — свои (оформление заказа, оплата). Если объединить эти процессы в один контекст, сложность возрастёт. Разделение на контексты "Управление товарами" и "Оформление заказов" упрощает работу и масштабируемость.

Контексты не существуют в изоляции, они взаимодействуют друг с другом. Варианты взаимодействия:

1. Контракт на уровне API — один контекст предоставляет другой API, минимизируя зависимость.
2. Событийная интеграция — один контекст публикует события, а другой реагирует на них (например, "Заказ оформлен" инициирует списание товара со склада).
3. Анти-коррупционный слой (ACL) — промежуточный слой, адаптирующий данные одного контекста для другого.

Bounded Context (Границы контекста) — фундаментальный инструмент DDD, позволяющий разрабатывать масштабируемые и легко поддерживаемые системы. Четко определённые контексты упрощают разработку, делают код понятным и минимизируют нежелательные зависимости. Важно учитывать бизнес-цели, терминологию и организационные аспекты при определении границ контекста.