Мы уже знаем, что модель в DDD — это не просто набор данных, а живое отражение бизнес-процессов. Но как быть, когда бизнес огромен и сложен? Попытка создать одну всеобъемлющую модель для всей компании обречена на провал. Она станет громоздкой, запутанной и полной противоречий. Секрет успеха — в умении проводить границы, разделяя большую проблему на управляемые части.

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

Для начала давайте четко разделим два ключевых понятия: поддомен (Subdomain) и ограниченный контекст (Bounded Context). Их часто путают, хотя они описывают совершенно разные вещи.

Поддомен — это часть проблемного пространства. Это реальная, существующая часть вашего бизнеса. Например, в интернет-магазине есть поддомены: управление каталогом товаров, обработка заказов, логистика, клиентская поддержка. Они существуют независимо от того, пишете вы для них код или нет.

Ограниченный Контекст — это часть пространства решений. Это граница, внутри которой существует конкретная модель. Внутри этой границы каждый термин из Единого Языка (Ubiquitous Language) имеет одно, четкое и непротиворечивое значение.

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

Как найти эти невидимые швы в монолите бизнеса? Слушайте, как говорят люди. Язык — самый надежный индикатор границ. Один и тот же термин может иметь совершенно разный смысл в разных отделах.

Возьмем слово «Клиент».

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

Попытка создать единый объект Клиент со всеми этими полями приведет к созданию монстра. Правильное решение — создать три разные модели Клиента в трех разных ограниченных контекстах: Продажи, Бухгалтерия и Поддержка. Внутри каждого контекста модель будет простой, чистой и сфокусированной на своей задаче.

Чтобы найти эти границы, анализируйте документы, слушайте разговоры на совещаниях, проводите сессии Event Storming. Цель — выявить, где значение слов меняется. Там, где происходит смысловой сдвиг, скорее всего, и проходит граница ограниченного контекста.

Определив границы контекста, мы должны стремиться к чистоте модели внутри него. Здесь нам на помощь приходят два классических принципа проектирования: высокая связность (cohesion) и низкое зацепление (coupling).

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

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

Теперь, когда вы понимаете эти стратегические принципы, давайте проверим ваши знания.

Умение правильно определять границы — ключ к созданию поддерживаемых и масштабируемых систем.