Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ Проектирование Программирование Конструирование Тестирование Отладка Развёртывание Сопровождение Документирование
Парадигмы и модели
Agile Cleanroom Итеративная Спиральная Каскадная V-Model Dual Vee Model
Методологии
ASD DevOps DAD DSDM FDD Канбан Lean SD LeSS MDD MSF PSP OpenUP RAD RUP SAFe SCRUM UP XP
Инструменты
Компилятор Отладчик Профилирование GUI-конструктор ИСР Автоматизация сборки Инструменты тестирования

Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design , DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей . В эти модели входит бизнес-логика , устанавливающая связь между реальными условиями области применения продукта и кодом.

Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс проектирования программного обеспечения в незнакомой предметной области.

Подход DDD особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать ПО , но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.

Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design» .

Основные определения

• Область ( англ. domain ) — предметная область , для которой разрабатывается программное обеспечение .
• Модель ( англ. model ) — описывает отдельные аспекты области и может быть использована для решения проблемы.
• Язык описания — используется для единого стиля описания домена и модели.

Концепция

В идеале, при проектировании хочется иметь одну-единственную модель, которая полностью описывает всю предметную область, но в реальности, для упрощения процесса разработки продукта, домен представляют в виде сочетания нескольких взаимосвязанных моделей.

Схема архитектуры приложения представляет собой описание одной или нескольких моделей предметной области и их взаимосвязей между собой.

Ограниченные связи

Использование нескольких моделей на различных уровнях проекта . Данный подход используется для уменьшения различных связей между моделями, что исключает сложность и запутанность кода . Иногда бывает неясно, в каком именно контексте должна использоваться модель.

Решение: Точно определить контекст, в котором используется модель. Определить границы использования данной модели и её характеристики.

Целостность

Когда над проектом работает большое количество людей, то есть тенденция дробить модель на несколько более мелких фрагментов. Чем больше людей, тем более значительна данная проблема. В конечном итоге теряется целостность проекта.

Решение: Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством тестирования . Это позволяет держаться всем разработчикам в одной большой концепции.

Взаимосвязь

При работе над несколькими отдельными моделями в большой группе, различные члены команды могут не знать о сущностях других моделей, что усложняет процесс общей сборки конечного продукта.

Решение: На этапе проектирования точно обозначьте, что именно выполняет каждая модель и как она взаимосвязана с другими моделями. В конечном итоге у вас должна получиться карта взаимосвязей моделей.

Элементы DDD

При проектировании на основе предметно-ориентированного подхода используются следующие понятия:

Ограниченный контекст

В большинстве систем для предприятий используются крупномасштабные зоны ответственности. В DDD этот высший уровень организации называется ограниченным контекстом. Например, система биллинга крупной телекоммуникационной компании может иметь следующие ключевые элементы:

• клиентская база
• система безопасности и защиты
• резервное копирование
• взаимодействие с платежными системами
• ведение
• администрирование
• система уведомлений

Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль , который имеет красноречивое название « Большой ком грязи » в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).

Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках.

Сущность

Проще всего сущности выражать в виде существительных : люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более слабо связанном коде можно найти массу служебных или управляющих классов , проверяющих сущности снаружи.

Объект-значение

Объект-значение — это свойства, важные в той предметной области , которую вы моделируете. У них, в отличие от сущностей, нет обозначения; они просто описывают конкретные сущности, которые уже имеют обозначения. Полезность объектов-значений состоит в том, что они описывают свойства сущностей гораздо более изящным и объявляющим намерения способом. Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода . После их создания, внесение поправок невозможно.

Агрегат

Агрегат — специальная сущность, к которой напрямую обращаются потребители. Использование агрегатов позволяет избегать чрезмерного соединения объектов между собой, составляющих модель. Это позволяет избежать путаницы и упростить структуру, потому что не позволяет создавать тесно связанные системы.

Службы предметных областей

Иногда в предметной области есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс , не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести многослойную архитектуру , так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.

Взаимосвязь с подходами программирования

Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны объектно-ориентированного программирования . Это использование наследования , инкапсуляции , представления в виде методов и классов. Нужно помнить, что предметно-ориентированный подход может быть применен не только к ООП языкам, таким как Java , C# или C++ , но так же и к функциональным — F# , Erlang . Особенно удобны языки, поддерживающие создание и использование собственных предметно-ориентированных языков , такие как Scala (см. также ЯОП ).

См. также

• Парадигма программирования
• Предметно-ориентированный язык
• Объектно-ориентированное проектирование
• Агентно-ориентированный подход
• Языково-ориентированное программирование
• Унифицированный язык моделирования (UML)

Примечания

Литература

• Вон Вернон. Реализация методов предметно-ориентированного проектирования = Implementing Domain: Driven Design. — М. : , 2016. — 688 с. — ISBN 978-0-321-83457-7 .

• Эрик Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем = Domain-Driven Design: Tackling Complexity in the Heart of Software. — М. : , 2011. — 448 с. — ISBN 978-5-8459-1597-9 .
• Нильссон Д. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET = Applying Domain-Driven Design and Patterns with Examples in C# and .NET. — М. : , 2008. — 549 с. — ISBN 978-5-8459-1296-1 .
• Evans E. Domain-Driven Design - Tackling Complexity in the Heart of Software. — Addison-Wesley, 2004. — 529 с. — ISBN 978-0-3211-2521-7 .

• Brian F., Joseph Y. Big Ball of Mud. — Urbana, IL 61801 USA, 1999. — 41 с.
• Nick Tune, Scott Millett. Patterns, Principles And Practices Of Domain-driven Design. — 1-е изд. — "John Wiley & Sons" , 2015. — 792 с. — ISBN 978-1118714706 . — ISBN 1118714709 .

Ссылки

• от 18 мая 2011 на Wayback Machine (рус.)
• от 30 апреля 2012 на Wayback Machine (англ.)
• от 22 мая 2012 на Wayback Machine (англ.)
• (англ.)
• от 14 апреля 2021 на Wayback Machine (англ.)
• от 17 мая 2012 на Wayback Machine (англ.)
• (англ.)
• (недоступная ссылка) (англ.)
• от 12 августа 2011 на Wayback Machine (англ.)
• от 21 июня 2013 на Wayback Machine (англ.)
• от 9 мая 2012 на Wayback Machine (англ.)
• от 10 февраля 2012 на Wayback Machine (англ.)
• от 9 марта 2012 на Wayback Machine (англ.)
• от 3 марта 2021 на Wayback Machine (англ.)
• от 7 февраля 2012 на Wayback Machine (англ.)
• от 6 июня 2012 на Wayback Machine (англ.)
• от 25 октября 2016 на Wayback Machine (англ.)

Видео

• от 26 декабря 2015 на Wayback Machine (рус.)
• от 9 марта 2012 на Wayback Machine (англ.)
• от 9 мая 2012 на Wayback Machine (англ.)