Проектирование на основе предметной области ( DDD ) — это основной подход к проектированию программного обеспечения , [1] фокусирующийся на моделировании программного обеспечения для соответствия предметной области в соответствии с данными, полученными от экспертов этой предметной области. [2] DDD выступает против идеи наличия единой унифицированной модели; вместо этого он делит большую систему на ограниченные контексты, каждый из которых имеет свою собственную модель. [3] [4]
В рамках доменно-ориентированного проектирования структура и язык программного кода (имена классов, методы классов , переменные классов ) должны соответствовать бизнес-домену. Например: если программное обеспечение обрабатывает заявки на кредит, оно может иметь такие классы, как «заявка на кредит», «клиенты», и такие методы, как «принять предложение» и «отозвать».
Проектирование, ориентированное на предметную область, основано на следующих целях:
Критики доменно-ориентированного проектирования утверждают, что разработчики обычно должны реализовывать значительную часть изоляции и инкапсуляции, чтобы поддерживать модель как чистую и полезную конструкцию. Хотя доменно-ориентированное проектирование обеспечивает такие преимущества, как удобство обслуживания, Microsoft рекомендует его только для сложных доменов, где модель обеспечивает явные преимущества в формулировании общего понимания домена. [5]
Термин был введен Эриком Эвансом в его одноименной книге, опубликованной в 2003 году. [6]
Проектирование, ориентированное на предметную область, формулирует ряд концепций и практик высокого уровня. [6]
Первостепенное значение имеет домен программного обеспечения, предметная область, к которой пользователь применяет программу. Разработчики программного обеспечения строят модель домена : систему абстракций, которая описывает выбранные аспекты домена и может использоваться для решения проблем, связанных с этим доменом.
Эти аспекты проектирования, основанного на домене, направлены на содействие общему языку, разделяемому экспертами в домене, пользователями и разработчиками — универсальному языку . Универсальный язык используется в модели домена и для описания системных требований.
Единый язык является одним из столпов DDD наряду со стратегическим и тактическим проектированием .
В доменно-ориентированном проектировании уровень домена является одним из общих уровней в объектно-ориентированной многослойной архитектуре .
Проектирование на основе домена распознает несколько видов моделей. Например, сущность — это объект, определяемый не своими атрибутами, а своей идентичностью . Например, большинство авиакомпаний присваивают уникальный номер местам на каждом рейсе: это идентичность места. Напротив, объект-значение — это неизменяемый объект, который содержит атрибуты, но не имеет концептуальной идентичности. Например, когда люди обмениваются визитными карточками, их интересует только информация на карте (ее атрибуты), а не попытки отличить каждую уникальную карту.
Модели также могут определять события (что-то, что произошло в прошлом). Событие предметной области — это событие, которое интересует экспертов предметной области. Модели могут быть связаны вместе корневой сущностью, чтобы стать агрегатом . Объектам вне агрегата разрешено хранить ссылки на корень, но не на любой другой объект агрегата. Корень агрегата проверяет согласованность изменений в агрегате. Водителям не нужно индивидуально управлять каждым колесом автомобиля, например: они просто ведут автомобиль. В этом контексте автомобиль — это агрегат нескольких других объектов (двигатель, тормоза, фары и т. д.).
В предметно-ориентированном проектировании создание объекта часто отделено от самого объекта.
Например, репозиторий — это объект с методами для извлечения объектов домена из хранилища данных (например, базы данных). Аналогично, фабрика — это объект с методами для непосредственного создания объектов домена.
Когда часть функциональности программы концептуально не принадлежит ни одному объекту, она обычно выражается как служба .
Существуют различные типы событий в DDD, и мнения об их классификации могут различаться. По словам Янь Цуя, существуют две основные категории событий: [7]
События домена обозначают важные события в определенном бизнес-домене. Эти события ограничены ограниченным контекстом и жизненно важны для сохранения бизнес-логики. Обычно события домена имеют более легкую полезную нагрузку , содержащую только необходимую информацию для обработки. Это связано с тем, что прослушиватели событий обычно находятся в пределах одной и той же службы, где их требования более четко понятны. [7]
С другой стороны, события интеграции служат для передачи изменений в различных ограниченных контекстах. Они имеют решающее значение для обеспечения согласованности данных во всей системе. События интеграции, как правило, имеют более сложную полезную нагрузку с дополнительными атрибутами , поскольку потребности потенциальных слушателей могут значительно различаться. Это часто приводит к более тщательному подходу к коммуникации, что приводит к избыточной коммуникации для обеспечения эффективного обмена всей релевантной информацией. [7]
Ограниченный контекст аналогичен микросервису . [ 8]
Хотя доменно-ориентированное проектирование не связано по своей сути с объектно-ориентированными подходами , на практике оно использует преимущества таких методов. К ним относятся сущности/агрегированные корни как приемники команд/вызовов методов, инкапсуляция состояния в передовых агрегатных корнях и на более высоком архитектурном уровне ограниченные контексты.
В результате, доменно-ориентированное проектирование часто ассоциируется с Plain Old Java Objects и Plain Old CLR Objects , которые являются техническими деталями реализации, специфичными для Java и .NET Framework соответственно. Эти термины отражают растущую точку зрения, что доменные объекты должны определяться исключительно бизнес-поведением домена, а не более конкретной технологической структурой.
Аналогично, шаблон голых объектов утверждает, что пользовательский интерфейс может быть просто отражением достаточно хорошей модели домена. Требование, чтобы пользовательский интерфейс был прямым отражением модели домена, заставит разработать лучшую модель домена. [9]
Проектирование на основе предметной области оказало влияние на другие подходы к разработке программного обеспечения.
Например, предметно-ориентированное моделирование — это предметно-ориентированное проектирование, применяемое с предметно-ориентированными языками . Предметно-ориентированное проектирование не требует использования предметно-ориентированного языка, хотя его можно использовать для определения предметно-ориентированного языка и поддержки предметно-ориентированного мультимоделирования .
В свою очередь, аспектно-ориентированное программирование позволяет легко исключить технические проблемы (такие как безопасность, управление транзакциями, ведение журнала) из модели предметной области, позволяя сосредоточиться исключительно на бизнес-логике.
Хотя доменно-ориентированное проектирование совместимо с инженерией на основе моделей и архитектурой на основе моделей , [10] намерение, лежащее в основе этих двух концепций, различно. Архитектура на основе моделей больше связана с переводом модели в код для различных технологических платформ, чем с определением лучших доменных моделей.
Однако методы, предоставляемые инженерией на основе моделей (для моделирования доменов, для создания доменно-специфических языков для облегчения общения между экспертами и разработчиками в доменах,...) облегчают проектирование на основе доменов на практике и помогают практикам извлечь больше пользы из своих моделей. Благодаря методам преобразования моделей и генерации кода инженерии на основе моделей, модель домена может быть использована для создания фактической программной системы, которая будет ею управлять. [11]
Разделение ответственности команд и запросов (CQRS) — это архитектурный шаблон для разделения чтения данных («запрос») от записи данных («команда»). CQRS происходит от разделения команд и запросов (CQS), придуманного Бертраном Мейером .
Команды мутируют состояние и приблизительно эквивалентны вызову метода на агрегированных корнях или сущностях. Запросы считывают состояние, но не мутируют его.
Хотя CQRS не требует проектирования на основе домена, он делает различие между командами и запросами явным с помощью концепции совокупного корня. Идея заключается в том, что данный совокупный корень имеет метод, который соответствует команде, а обработчик команд вызывает метод на совокупном корне.
Агрегатный корень отвечает за выполнение логики операции и либо выдачу ответа об ошибке, либо просто мутацию своего собственного состояния, которое может быть записано в хранилище данных. Обработчик команд берет на себя инфраструктурные проблемы, связанные с сохранением состояния агрегатного корня и созданием необходимых контекстов (например, транзакций).
Источник событий — это архитектурный шаблон, в котором сущности отслеживают свое внутреннее состояние не посредством прямой сериализации или объектно-реляционного отображения, а путем чтения и фиксации событий в хранилище событий .
Когда источник событий сочетается с CQRS и доменно-ориентированным проектированием, агрегированные корни отвечают за проверку и применение команд (часто путем вызова их методов экземпляра из обработчика команд), а затем за публикацию событий. Это также основа, на которой агрегированные корни строят свою логику для работы с вызовами методов. Таким образом, входные данные представляют собой команду, а выходные данные представляют собой одно или несколько событий, которые сохраняются в хранилище событий, а затем часто публикуются на брокере сообщений для заинтересованных лиц (например, в представлении приложения ).
Моделирование агрегированных корней для выходных событий может изолировать внутреннее состояние даже больше, чем при проецировании данных чтения из сущностей, как в стандартных n -уровневых архитектурах передачи данных. Одним из существенных преимуществ является то, что аксиоматические доказатели теорем (например, Microsoft Contracts и CHESS [12] ) проще в применении, поскольку агрегированный корень полностью скрывает свое внутреннее состояние. События часто сохраняются на основе версии экземпляра агрегированного корня, что дает модель домена, которая синхронизируется в распределенных системах посредством оптимистичного параллелизма .
Хотя предметно-ориентированное проектирование не зависит от какого-либо конкретного инструмента или фреймворка, вот некоторые примечательные примеры: