Когда продукт растёт, слова вроде «клиент», «заказ», «договор» или «платёж» перестают быть очевидными. Для разных подразделений один термин может означать разные вещи, а система тем временем пытается свести всё к одной универсальной модели.
В результате простое изменение начинает требовать переговоров между несколькими командами, а бизнес-правила оказываются размазаны по сервисам, таблицам и интеграциям.
Какую проблему мы решаем
Domain-Driven Design предлагает строить систему вокруг предметной области: реальных бизнес-процессов, правил и терминов.
Ключевая идея — не пытаться создать одну универсальную модель на всю компанию. Разные части бизнеса могут иметь собственные понятия и границы. В DDD такую смысловую границу часто описывает Bounded Context: внутри неё термины и правила должны быть непротиворечивыми.
DDD не означает обязательный набор классов, агрегатов или микросервисов. Это прежде всего способ сделать бизнес-модель и границы ответственности явными.
Что получает бизнес
Главная ценность — меньше скрытой координации при изменениях.
Если понятна граница домена и у него есть владелец, изменение одного бизнес-процесса реже требует синхронной переделки половины компании. Это сокращает стоимость изменений и делает ответственность заметнее.
Единый язык внутри домена также уменьшает дорогие ошибки понимания. Когда бизнес говорит «активный клиент», а система использует тот же термин в том же смысле, меньше шансов, что требование потеряется при переводе из презентации в код.
Для бизнеса DDD особенно полезен там, где правила сложные и часто меняются. Если предметная область проста, инвестиция в моделирование может оказаться дороже самой проблемы.
Что получает команда
Команда получает более ясные границы: какие правила принадлежат ей, какие данные она контролирует и с кем должна интегрироваться через явный контракт.
Но одной границы недостаточно. Нужно понимать и отношения между доменами: кто от кого зависит, где переводится модель и где возникает совместная ответственность. Для этого полезен Context Mapping.
Обсуждение архитектуры становится ближе к обсуждению бизнеса. Вместо «куда положить этот класс» появляется вопрос «к какой части бизнеса относится это правило».
Но DDD требует времени экспертов предметной области. Если бизнес недоступен для совместного моделирования, команда легко построит красивую, но неверную модель.
Что получает клиент
Клиент не видит DDD напрямую. Он получает более косвенный результат: продукт точнее отражает реальные правила и меньше ломается на границах между подразделениями.
Новые сценарии могут появляться быстрее, потому что изменения локализованы внутри понятного домена, а не требуют переписывания общей модели для всех.
Чем мы за это платим
DDD требует времени на разговоры, моделирование и пересмотр границ. Это не «архитектура за вечер».
Появляется риск увлечься терминологией и ритуалами. Если команда обсуждает названия паттернов больше, чем реальные бизнес-проблемы, подход начинает работать против себя.
Также нельзя автоматически превращать каждый домен в отдельный микросервис. Граница модели и граница deployment — не одно и то же решение.
И важно помнить, что архитектурные границы редко живут отдельно от устройства компании: Conway’s Law объясняет, почему структура коммуникаций команд всё равно начинает проявляться в структуре систем.
Когда DDD не нужен
Для простого CRUD-продукта с небольшим количеством правил и одной компактной командой глубокое доменное моделирование часто избыточно.
DDD начинает окупаться там, где бизнес-логика сложна, терминология неоднозначна, команд много, а стоимость непонимания и координации уже заметна.
Что стоит спросить перед решением
- Где сегодня бизнес и разработка используют одинаковые слова в разном смысле?
- Какие изменения постоянно требуют участия нескольких команд?
- Какие бизнес-правила сложнее всего объяснять и тестировать?
- Есть ли у доменов реальные владельцы со стороны бизнеса?
- Не пытаемся ли мы решить простую задачу слишком тяжёлым методом?
В итоге
DDD ценен не потому, что добавляет архитектуре новые термины. Он делает предметную область главным источником структуры системы.
Хороший результат DDD — когда бизнес, команда и код начинают говорить об одной и той же реальности примерно одним языком.