Главная › Domain Driven Design › Что такое DDD

Что такое DDD и зачем он нужен

Введение в DDD: зачем нужен, когда применять, основные концепции.

что такое DDD

Все примеры в статье — на сквозном кейсе сайта: высоконагруженный маркетплейс.

Что такое DDD? Domain-Driven Design — это подход к разработке, в котором структура и язык кода привязаны к бизнес-домену. Не к фреймворку, не к базе данных, не к API — а к тому, как бизнес описывает свои процессы. Термин ввёл Эрик Эванс в книге «Domain-Driven Design: Tackling Complexity in the Heart of Software» (2003).

Это первая статья из серии о DDD для Java-разработчиков. Здесь — общая картина: зачем нужен DDD, когда его стоит применять и как устроена серия. Если вы задаётесь вопросом что такое DDD и стоит ли его внедрять — начните с этой статьи. Детали — в отдельных статьях по ссылкам ниже.

Что такое DDD: проблема, которую он решает

Представь типичный enterprise-проект через два года разработки:

  • Бизнес говорит на одном языке, код — на другом. Менеджер говорит «заявка», в коде — Request, Order, Ticket и Application в разных сервисах.
  • Изменение бизнес-правила ломает всё. «Добавить скидку для VIP» превращается в правку 15 файлов, потому что логика размазана по контроллерам, сервисам и SQL.
  • Модули тянут друг друга. Платёжный модуль знает про склад, склад знает про уведомления. Любое изменение — каскад.
  • Новый разработчик тонет. Онбординг занимает месяцы, потому что нет явной структуры и единого языка.

DDD атакует эти проблемы на нескольких уровнях: стратегическом (как разбить систему на части), тактическом (как писать код внутри каждой части), интеграционном (как части общаются между собой) и на уровне принципов проектирования (как думать при построении модели).

Ключевые концепции DDD

Прежде чем разбирать когда применять DDD, важно понять его основные концепции:

  • Ubiquitous Language — единый язык, на котором говорят разработчики и бизнес. Термины из кода совпадают с терминами из бизнес-процессов.
  • Bounded Context — граница, внутри которой термины имеют однозначный смысл. "Заказ" в контексте оплаты и "заказ" в контексте доставки — разные модели.
  • Aggregate — кластер связанных объектов с корнем, через который проходят все изменения. Обеспечивает целостность данных.
  • Domain Event — факт, который произошёл в домене. "Заказ подтверждён", "Платёж принят" — события, на которые реагируют другие контексты.

Каждая из этих концепций подробно разобрана в отдельных статьях серии.

Когда DDD нужен, а когда нет

DDD оправдан, когда:

  • Бизнес-логика нетривиальна и часто меняется
  • Проект долгоживущий (годы, не месяцы)
  • Несколько команд работают над одной системой
  • Домен сложный: маркетплейс, финансы, логистика, страхование
  • Разработчики и бизнес-эксперты могут регулярно общаться

DDD избыточен, когда:

  • Приложение — простой CRUD без бизнес-логики
  • Маленькая команда, один контекст, понятные требования
  • Прототип или MVP, который нужно запустить быстро
  • Нет доступа к бизнес-экспертам

Хорошее правило: если вся бизнес-логика помещается в один if в контроллере — DDD вам не нужен. Если бизнес-правила занимают 500 строк и растут — пора задуматься.

Если вы решили попробовать DDD, вот практический план:

  1. Поговорите с бизнесом. Event Storming — отличный формат для первой встречи. Соберите команду, выпишите все события в домене.
  2. Зафиксируйте глоссарий. Составьте список терминов — это ваш Ubiquitous Language.
  3. Определите контексты. Нарисуйте Context Map — кто с кем общается, кто от кого зависит.
  4. Классифицируйте поддомены. Где ваш Core Domain? Не тратьте силы на DDD в Generic Subdomain.
  5. Начните с одного контекста. Выберите Core Domain, подключите ddd-building-blocks и примените тактические паттерны. Не пытайтесь переписать всё сразу.

Частая ошибка: начинать с тактических паттернов, не разобравшись со стратегическими. Сначала — границы и язык, потом — код. Понимание что такое DDD на стратегическом уровне важнее, чем знание конкретных паттернов кода.

Что такое DDD: рекомендуемые книги

  • «Domain-Driven Design Distilled» (Vaughn Vernon) — краткий обзор на 150 страниц. Идеально для старта.
  • «Implementing Domain-Driven Design» (Vaughn Vernon) — практичнее Эванса, с примерами на Java.
  • «Learning Domain-Driven Design» (Vlad Khononov) — современный взгляд с практическими примерами.
  • «Domain-Driven Design» (Eric Evans) — оригинальная книга. Фундаментальная, но тяжёлая. Лучше после практического знакомства.