Domain Driven Design - методология и методическое задание для разработки сложных систем, целью которых является сопоставление действий, задач, событий и данных в проблемной области с технологическими артефактами в области решения.
Основной упор в предметно-ориентированном проектировании заключается в понимании проблемной области с целью создания абстрактной модели проблемной области, которая затем может быть реализована в определенном наборе технологий. В основе методологии доменного проектирования лежит руководство по тому, как разработка этой модели и развитие технологий могут привести к созданию системы, которая отвечает потребностям людей, использующих ее, и в то же время будет устойчивой к изменениям в проблемной области.
Процессная сторона Domain Driven Design включает в себя сотрудничество между экспертами домена, людьми, которые знают проблемную область, и экспертами по дизайну / архитектуре, людьми, которые знают домен решений. Идея состоит в том, чтобы иметь общую модель с общим языком, чтобы, когда люди из этих двух разных областей со своими двумя разными взглядами обсуждали решение, они фактически обсуждают общую базу знаний с общими понятиями.
Отсутствие общего понимания проблемной области между людьми, которым нужна конкретная система, и людьми, которые проектируют и внедряют систему, кажется основным препятствием для успешных проектов. Домен-управляемый дизайн является методологией для устранения этого препятствия.
Это больше, чем объектная модель. На самом деле основное внимание уделяется общению и улучшению совместной работы, чтобы можно было выявить реальные потребности в проблемной области и создать соответствующее решение для удовлетворения этих потребностей.
Домен-управляемый дизайн: хорошее и сложное дает краткий обзор с этим комментарием:
DDD помогает обнаружить архитектуру верхнего уровня и информировать о
Механика и динамика области, в которой нуждается программное обеспечение
реплицировать. Конкретно, это означает, что хорошо выполненный анализ DDD
сводит к минимуму недоразумения между экспертами в области и программным обеспечением
архитекторы, и это уменьшает последующее количество дорогих запросов
для изменения. Разбивая сложность домена на меньшие контексты,
DDD избегает принуждения архитекторов проекта к созданию раздутого объекта
модель, где много времени теряется в разработке
детали реализации - отчасти потому, что количество объектов для
дело часто выходит за рамки досок для конференций.
См. Также эту статью. Архитектура, управляемая доменом, для архитектуры служб , в которой приведен краткий пример. В статье приводится следующее описание миниатюрного доменного дизайна.
Domain Driven Design поддерживает моделирование, основанное на реальности
бизнес в соответствии с нашими вариантами использования. Как сейчас стареет и
уровень обмана снижается, многие из нас забывают, что подход DDD действительно
помогает в понимании проблемы и разработки программного обеспечения для
общее понимание решения. При создании приложений,
DDD говорит о проблемах как доменов, так и поддоменов. Он описывает
независимые шаги / области проблем как ограниченные контексты, подчеркивает
общий язык, чтобы говорить об этих проблемах, и добавляет много технических
понятия, такие как сущности, объекты значения и агрегировать корневые правила для
поддержать реализацию.
Мартин Фаулер написал несколько статей, в которых в качестве методологии упоминается доменно-управляемый дизайн. Например, эта статья, BoundedContext , предоставляет обзор концепции ограниченного контекста из разработки, управляемой доменом.
В те молодые годы нам посоветовали построить единую модель
весь бизнес, но DDD признает, что мы узнали, что "всего
унификация доменной модели для большой системы не будетосуществимый или экономически эффективный " 1 . Таким образом, вместо этого DDD разделяет большую систему на ограниченные контексты, каждый из которых может иметь унифицированную модель - по сути, способ структурирования MultipleCanonicalModels.