Введение
Domain-Driven Design (DDD) – методология проектирования программного обеспечения, в которой структура и язык кода (имена классов, методов, переменных) должны соответствовать бизнес-домену. Подход введён Эриком Эвансом в книге «Domain-Driven Design: Tackling Complexity in the Heart of Software» (2003).
DDD предполагает тесное взаимодействие разработчиков с экспертами предметной области (domain experts) для создания единой модели, понятной обеим сторонам. Это не только технический, но и коммуникационный подход.
История и контекст
До DDD разработчики создавали технические модели, оторванные от бизнеса: «таблица Users», «класс DataProcessor». Эрик Эванс в «синей книге» (Blue Book) систематизировал практики создания моделей, отражающих реальный бизнес. Позднее Вон Вернон в «красной книге» (Implementing Domain-Driven Design, 2013) предложил конкретные паттерны реализации. DDD получил второе рождение с расцветом микросервисов: Bounded Context стал главным инструментом определения границ сервисов.
Как это работает
Стратегическое DDD – работа с большой картиной:
- Ubiquitous Language – единый язык, используемый командой и в коде, и в переговорах с бизнесом;
- Bounded Context – явная граница, внутри которой модель и язык имеют чёткий смысл. Разные контексты – разные модели одного понятия;
- Context Map – карта взаимодействий между Bounded Context'ами.
Тактическое DDD – паттерны реализации:
- Entity – объект с идентификатором (Order, User);
- Value Object – неизменяемый объект без идентификатора (Money, Address);
- Aggregate – кластер объектов с единым корнем (Aggregate Root), защищающий инварианты;
- Domain Event – факт, произошедший в домене (OrderPlaced);
- Repository – интерфейс для доступа к агрегатам.
Где применяется
- Сложные корпоративные системы с богатой бизнес-логикой (ERP, финтех, страхование);
- Микросервисные архитектуры – Bounded Context как граница сервиса;
- Event Sourcing системы – Domain Event как единица хранения;
- Российские enterprise-разработки на 1С, Java, .NET с применением CQRS.
Преимущества и ограничения
Преимущества: код отражает бизнес-реальность, улучшается коммуникация команды; чёткие границы снижают coupling; Aggregate защищает инварианты. Хорошо масштабируется при сложном домене.
Ограничения: высокий порог входа; требует значительных инвестиций во взаимодействие с бизнесом; избыточен для простых CRUD-систем; правильное определение Bounded Context и Aggregate – нетривиальная задача.
Связь с другими понятиями
DDD – основа для микросервисов: Bounded Context определяет границы сервиса. CQRS и Event Sourcing – тактические паттерны, органично вписывающиеся в DDD. Event-driven Architecture распространяет Domain Events за пределы Bounded Context. Монолит также может строиться по DDD-принципам – в виде модульного монолита с чёткими контекстами.
