DDD, или Domain-Driven Design (предметно-ориентированное проектирование), — это не технология, а набор принципов, ускоряющих проектирование в сложных областях с запутанной бизнес-логикой. Он помогает снизить сложность за счет фокуса на предметной области.
Домен и субдомены
DDD-подход основан на выделении логики в домены. Домен — это предметная область, для которой ведется разработка. Например, термины и понятия бухгалтерского учета отличаются от банковской сферы или общепита. Важно учитывать специфическую терминологию и процессы, важные для заказчика. Разработка не должна быть оторвана от бизнес-задач.
В рамках доменов выделяются субдомены (subdomains). В онлайн-агентстве путешествий, например, домен может быть разбит на субдомены: авиабилеты и бронирование гостиниц.
Ubiquitous Language: единый язык
В отличие от подхода, где программист фокусируется на технологиях (базы данных, библиотеки), DDD ставит во главу угла бизнес-задачи. Ubiquitous Language (единый язык) — это язык, на котором разговаривают разработчики и бизнес-эксперты. Для его создания нужно:
- Определить ключевые бизнес-процессы, их входы и выходы.
- Создать глоссарий терминов и определений.
- Определить важные концепции программного обеспечения.
- Обеспечить хорошую документацию и обмен знаниями между командой и экспертами предметной области.
Стратегическое и тактическое моделирование
DDD включает стратегическое (Strategic Design) и тактическое (Tactical Design) моделирование.
Стратегическое моделирование фокусируется на стратегии управления бизнесом, определении внутренних взаимосвязей и создании системы раннего предупреждения. С технической стороны, оно защищает каждую бизнес-услугу, способствуя сервис-ориентированной архитектуре.
Тактическое моделирование предоставляет инструменты для итеративного моделирования, позволяя создавать корректное, тестируемое и менее подверженное ошибкам программное обеспечение.
Ограниченный контекст
Bounded Context (ограниченный контекст) – это граница, внутри которой существует модель предметной области. Код делится на папки, файлы, пакеты и компоненты таким образом, чтобы изменения в одном контексте минимально влияли на другие. Это способствует эффективной командной работе и позволяет смелее вносить изменения в код.
Context Map (карта контекстов) показывает связи между ограниченными контекстами (например, клиент-поставщик).
Пример: простой блог
Рассмотрим проект простого блога с сущностями: Post (пост, черновик, лайки, реакции, просмотры) и Author (автор, почта, имя, фамилия). В примере показаны разные подходы к организации кода:
- Функциональный подход: вся логика в нескольких больших файлах (неудобно при масштабировании и командной работе).
- Смешанный подход: файлы сгруппированы по смыслу (лучше, чем первый, но файлы все еще большие).
- DDD подход: файлы разделены по папкам, соответствующим сущностям (лучше, но возможны циклические зависимости).
- DDD + Чистая архитектура: разделение по папкам с учетом DDD и избеганием циклических зависимостей (рекомендуемый подход). Внутри каждой сущности (например, Post) создаются подпапки для транспорта (transport), бизнес-логики (core), доступа к данным (repo).
Выводы
DDD — это не технология, а подход к разработке, фокусирующийся на предметной области. Он объединяет разработчиков и экспертов для создания единой базы знаний, используя Ubiquitous Language. DDD предоставляет инструменты стратегического и тактического моделирования для создания качественного ПО. DDD эффективен в сложных задачах, но не является панацеей и требует усилий от всех участников. Он представляет собой долгосрочную инвестицию, результатом которой должно быть удовлетворение потребностей бизнеса и клиентов. Выбор подхода зависит от сложности проекта. Для небольших проектов (около 2000 строк кода) может быть достаточно одного файла. Чистая архитектура является дополнением к DDD, но выходит за рамки данной статьи.