Что такое DDD?
Предметно-ориентированное проектирование - это набор правил, который позволяет принимать правильные проектные решения. Основная цель DDD - это борьба со сложностью бизнес-процессов. Данный подход особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать ПО, но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.
Описание
Данный подход позволяет значительно ускорить процесс разработки продукта (даже в незнакомой предметной области) от этапа зарождения идеи до финального релиза. Благодаря простым правилам, вся команда будет понимать, что происходит в конкретном месте за счет распределения контекста и зон ответсвенности между командой. Такой подход лучше всего подходит для проектов с тяжелой бизнес логикой, которую сложно разграничивать - распределяя ее небольшими кусками для упрощения понимания.
Доменная модель
- Core Domain - основной бизнес процесс, отвечающий за ценность продукта
- Support Domain - элементы приложения, которые составляют основной функционал, но не имеют отношения к ядру
- Generic Subdomain - что-то помогающее нашему бизнес-процессу, на что мы можем не тратить свои ресурсы
- Bounded Context - бизнес функционал, который описан бизнес аналитиками, является явной границей, внутри которой существует модель предметной области
Мне очень понравился пример описания доменной модели с рестораном:
- domain - ресторан
- core domain - кухня
- support domain - меню, маркетинг и т.д.
- generic subdomain - кассовый аппарат
Роадмап: аналитика -> проектирование -> разработка
- Работа с доменом начинается с анализа предметной области и составления требований.
- Ubiquitous language - единый язык домена, набор терминов, применяемый в модели домена для объяснения связей и действий, благодаря единой терминологии, все участники проекта, как внутри команды, так и заказчик смогут взаимодействовать на одном понятном языке для всех.
- С точки зрения Domain-Driven Design абсолютно всё равно, какую архитектуру вы выберете. Domain-Driven Design не про это, Domain-Driven Design про язык и про общение.
- Но DDD почти невозможен без чистой архитектуры проекта, так как при добавлении новой функциональности или изменении старой нужно стараться сохранять гибкость и прозрачность кодовой базы.
Плюсы:
- взаимодействие участников команды становится более продуктивным
- код становится легко читаемым и понятным, а изменение бизнес-логики проходит с минимальными затратами
- QA специалистам легко выявить ошибку
Минусы
- требуется высокая квалификация разработчика, подход довольно сложен и требует опыта
- не подходит для маленьких проектов
- долгий старт, все участники процесса должны научиться этому подходу