Subdomain и Bounded Context: как не перепутать границы

Subdomain и Bounded Context легко перепутать: оба понятия описывают границы, часто получают одинаковые названия и выглядят на схемах как одинаковые прямоугольники. Поэтому сложно понять, где заканчивается часть бизнеса и начинается архитектурное решение.

Путаница становится практической проблемой, к примеру, когда «Заказы» обозначают одновременно бизнес-процесс, модуль, таблицу и будущий микросервис. Команда делит систему по структуре кода и протаскивает одну модель туда, где одинаковые термины имеют разные значения.

Из статьи вы поймёте разницу между Subdomain и Bounded Context и получите способ проверить границы моделей в своём проекте.

Subdomain. Часть бизнеса с собственной задачей и правилами. Для платформы доставки это может быть приём заказов, назначение курьеров или расчёт выплат. Поддомен существует независимо от архитектуры: после замены монолита сервисами бизнес-задача остаётся.

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

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

Один объект можно моделировать по-разному, если меняются цели и правила. Для бухгалтерии сотрудник получает зарплату, для службы безопасности — имеет права доступа. Обе модели называются Employee и используют один Id, но содержат разные данные и поведение.

Без контекстов. Команда получила бы общий Employee с зарплатой, бонусом, признаком активности, уровнем доступа и сроком действия пропуска. Часть полей не нужна каждому сценарию, а изменение правил безопасности заставляет проверять код расчёта выплат. Похожие признаки IsActive и IsSuspended описывают разные причины, но в общей модели легко начинают влиять друг на друга.

Вот модель Employee в контексте Payroll. Она хранит только состояние, которое влияет на выплату: оклад, бонус и признак действующего трудового договора.

namespace Payroll; public sealed record Employee( Guid Id, decimal MonthlySalary, decimal MonthlyBonus, bool IsActive) { public decimal CalculateMonthlyPay() { if (!IsActive) { return 0m; } return MonthlySalary + MonthlyBonus; } }

Метод отвечает на один вопрос Payroll: сколько начислить сотруднику за месяц.

А это Employee в контексте Access Control. Здесь важны уровень доступа, блокировка пропуска и срок его действия.

namespace AccessControl; public enum AccessLevel { Office, ServerRoom } public sealed record Employee( Guid Id, AccessLevel Level, bool IsSuspended, DateTime AccessValidUntil) { public bool CanEnterServerRoom(DateTime now) { return !IsSuspended && Level == AccessLevel.ServerRoom && now <= AccessValidUntil; } }

Метод отвечает на вопрос Access Control: можно ли пропустить сотрудника в серверную сейчас. Payroll не зависит от правил пропуска, а Access Control — от формулы начисления. При обмене контексты передают Id и необходимые факты, а не общий класс Employee.

Поддомены ищут через бизнес-цели, решения, правила, события и конфликты терминов. Признаки границы:

Интервью, пользовательские сценарии и Event Storming дают гипотезу о поддоменах, которую проверяют с экспертами. Результат — карта бизнес-возможностей, а не список сервисов.

Затем команда проектирует Bounded Context с учётом продуктовых команд, транзакций и стоимости интеграции. Хорошая граница сохраняет модель согласованной, а большинство изменений — локальными.

В современной практике поддомен и Bounded Context чаще соответствуют друг другу 1:1. Компания делится на продуктовые команды, и каждая команда отвечает за бизнес-возможность, её модель, данные и контракты. Поэтому граница модели естественно следует за границей ответственности команды.

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

Такое разделение увеличивает число интеграций и переводов между моделями. Поэтому начинайте с 1:1, а несколько контекстов внутри поддомена вводите только для явно различающихся моделей. На карте фиксируйте поддомен, контексты, команды-владельцы и контракты между ними.

Не обязательно сразу создавать микросервисы. В монолите можно разделить пространства имён, модели, схемы данных и зависимости. Это даст обратную связь дешевле, чем раннее физическое разделение.