Определение Domain-Driven Design
В Domain-Driven Design понятия ПО следуют языку экспертов предметной области. Команды делают границы явными, защищают бизнес-инварианты и связывают стратегические решения с тактической реализацией.
Поисковый запрос «DDD» или «Domain-Driven Design» обычно означает определение подхода, разницу между стратегическим и тактическим проектированием и связь DDD с Bounded Contexts, Aggregates, Event Storming и CQRS.
- Единый язык экспертов и разработчиков
- Bounded Contexts как границы согласованного смысла
- Aggregates, защищающие бизнес-инварианты
- Явные отношения между моделями и процессами
Какую проблему решает Domain-Driven Design
По мере роста системы одинаковые слова получают разные значения, правила распределяются между сервисами, а решения растворяются в коде. DDD делает различия явными и помогает определить, где модель должна оставаться согласованной, а где требуется перевод между моделями.
- Согласовать понятия разработчиков и экспертов
- Разделить модели с разным смыслом и ответственностью
- Защитить бизнес-инварианты явными границами согласованности
- Связать стратегические решения с реализацией
Стратегическое и тактическое проектирование
Стратегическое проектирование делит систему на ограниченные контексты и описывает их отношения. Тактическое моделирование раскрывает поведение внутри контекста через агрегаты, команды, доменные события, политики и объекты-значения. Границы без поведения остаются прямоугольниками, а паттерны без границ превращаются в неконтролируемую общую модель.
DDD в разработке с ИИ
ИИ быстро создаёт реализацию, но ему всё равно нужен точный контекст: термины, границы, инварианты, процессы и ожидаемые результаты. Связанная доменная модель оставляет архитектурные решения за человеком и даёт ИИ более качественное основание для кода.
FAQ по Domain-Driven Design
Что такое Domain-Driven Design (DDD)?
Domain-Driven Design — подход к проектированию ПО, в котором архитектура строится вокруг знаний о предметной области, явных границ и единого языка команды. Он помогает моделировать бизнес-правила до реализации, особенно в сложных системах.
Когда стоит применять DDD?
DDD полезен, когда высока бизнес-сложность: одни термины имеют разные смыслы, правила часто меняются, а разные команды владеют разными частями домена. Для простого CRUD со стабильным языком обычно достаточно более лёгкого моделирования.
Чем стратегический DDD отличается от тактического?
Стратегический DDD делит систему на Bounded Contexts и описывает их отношения на Context Map. Тактический DDD моделирует поведение внутри контекста через Aggregates, Commands, Domain Events, Policies, Value Objects и Repositories.
Как DDD связан с CQRS и Event Storming?
Event Storming помогает обнаружить поведение домена и кандидатов в границы. Bounded Contexts и Aggregates упорядочивают смысл и инварианты. CQRS отделяет решения записи от моделей чтения, когда запросы требуют иной формы данных, чем write-модель.
Обязателен ли DDD вместе с микросервисами?
Нет. DDD — про модели и границы, а не про способ развёртывания. Bounded Context может жить в модульном монолите или в микросервисах. Начинайте с языка и ответственности, затем выбирайте deployment.
DDDesigner
Пример: оформление заказа
Business Action PlaceOrder начинается с намерения клиента. Event Storming выявляет OrderPlaced, оплату, резервирование и доставку. Context Map разделяет Ordering, Payments, Inventory и Shipping. Агрегат Order защищает инварианты, Сага координирует процесс, а CQRS-проекция обслуживает экран состояния заказа.
Начать бесплатно