Доменно-ориентированный дизайн

Доменно-ориентированное проектирование ( DDD ) — это основной подход к проектированию программного обеспечения . ^[1] сосредоточив внимание на программном обеспечении для моделирования, которое соответствует предметной области в соответствии с мнением экспертов этой области. ^[2]DDD выступает против идеи наличия единой унифицированной модели; вместо этого он делит большую систему на ограниченные контексты, каждый из которых имеет свою собственную модель. ^[3]

При проектировании, ориентированном на предметную область, структура и язык программного кода (имена классов, методы классов , переменные класса ) должны соответствовать предметной области бизнеса. Например: если программное обеспечение обрабатывает заявки на получение кредита, оно может иметь такие классы, как «заявка на получение кредита», «клиенты» и такие методы, как «принять предложение» и «снять».

Проектирование, ориентированное на предметную область, преследует следующие цели:

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

Критики предметно-ориентированного проектирования утверждают, что разработчикам обычно приходится реализовывать значительную изоляцию и инкапсуляцию, чтобы поддерживать модель как чистую и полезную конструкцию. Хотя проектирование на основе предметной области обеспечивает такие преимущества, как удобство обслуживания, Microsoft рекомендует его только для сложных предметных областей, где модель дает явные преимущества в формулировании общего понимания предметной области. ^[4]

Этот термин был придуман Эриком Эвансом в его одноименной книге, опубликованной в 2003 году. ^[5]

Обзор [ править ]

Проектирование, ориентированное на предметную область, объединяет ряд концепций и практик высокого уровня. ^[5]

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

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

Вездесущий язык является одним из столпов DDD наряду со стратегическим и тактическим проектированием .

В доменно-ориентированном проектировании уровень домена является одним из распространенных слоев объектно -ориентированной многоуровневой архитектуры .

Виды моделей [ править ]

Проектирование на основе предметной области распознает несколько типов моделей. Например, сущность — это объект, определяемый не его атрибутами, а его идентичностью . Например, большинство авиакомпаний присваивают местам на каждом рейсе уникальный номер: это идентификатор места. Напротив, объект значения — это неизменяемый объект, который содержит атрибуты, но не имеет концептуальной идентичности. Например, когда люди обмениваются визитными карточками, их волнует только информация на карте (ее атрибуты), а не попытки различить каждую уникальную карту.

Модели также могут определять события (то, что произошло в прошлом). Событие предметной области — это событие, о котором заботятся эксперты предметной области. Модели могут быть связаны вместе корневым объектом и стать агрегатом . Объектам вне агрегата разрешено содержать ссылки на корень, но не на какой-либо другой объект агрегата. Корень агрегата проверяет согласованность изменений в агрегате. Например, водителям не нужно индивидуально управлять каждым колесом автомобиля: они просто управляют автомобилем. В этом контексте автомобиль представляет собой совокупность нескольких других объектов (двигателя, тормозов, фар и т. д.).

Работа с моделями [ править ]

В доменно-ориентированном проектировании создание объекта часто отделено от самого объекта.

Например, репозиторий . — это объект с методами извлечения объектов предметной области из хранилища данных (например, базы данных) Аналогично, фабрика — это объект с методами для непосредственного создания объектов предметной области.

Когда часть функциональности программы концептуально не принадлежит какому-либо объекту, она обычно выражается как услуга .

с другими Связь идеями

Ограниченный контекст аналогичен микросервису . ^[6]

Хотя предметно-ориентированное проектирование по своей сути не связано с объектно-ориентированными подходами , на практике оно использует преимущества таких методов. К ним относятся сущности/агрегированные корни в качестве получателей команд/вызовов методов, инкапсуляция состояния внутри главных агрегатных корней, а на более высоком архитектурном уровне – ограниченные контексты.

В результате доменно-ориентированное проектирование часто ассоциируется с Plain Old Java Objects и Plain Old CLR Objects , которые представляют собой технически технические детали реализации, специфичные для Java и .NET Framework соответственно. Эти термины отражают растущее мнение о том, что объекты предметной области должны определяться исключительно бизнес-поведением предметной области, а не более конкретной технологической структурой.

Аналогичным образом, шаблон «голые объекты» утверждает, что пользовательский интерфейс может быть просто отражением достаточно хорошей модели предметной области. Требование, чтобы пользовательский интерфейс был прямым отражением модели предметной области, приведет к разработке лучшей модели предметной области. ^[7]

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

предметно-ориентированное моделирование Например, — это предметно-ориентированное проектирование, применяемое с помощью предметно-ориентированных языков . Проектирование, ориентированное на предметную область, не требует использования предметно-ориентированного языка, хотя его можно использовать для определения предметно-ориентированного языка и поддержки предметно-ориентированного мультимоделирования .

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

ориентированное проектирование и архитектура Модельно -

Хотя предметно-ориентированное проектирование совместимо с модельно-ориентированным проектированием и модельно-ориентированной архитектурой , ^[8]Цель этих двух концепций различна. Архитектура, управляемая моделями, больше занимается переводом модели в код для различных технологических платформ, чем определением лучших моделей предметной области.

Однако методы, предоставляемые модельно-ориентированным проектированием (моделирование предметных областей, создание предметно-ориентированных языков для облегчения общения между экспертами в предметной области и разработчиками...), облегчают предметно-ориентированное проектирование на практике и помогают практикам получить больше от своих проектов. модели. Благодаря методам преобразования моделей и генерации кода, используемым при проектировании на основе моделей, модель предметной области можно использовать для создания реальной программной системы, которая будет ею управлять. ^[9]

запрос Разделение командный ответственности за

Разделение ответственности за запрос команды (CQRS) — это архитектурный шаблон для разделения данных чтения («запрос») от записи в данные («команда»). CQRS происходит от разделения команд и запросов (CQS), придуманного Бертраном Мейером .

Команды изменяют состояние и примерно эквивалентны вызову метода для совокупных корней или сущностей. Запросы считывают состояние, но не изменяют его.

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

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

Источник событий [ править ]

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

Когда источник событий сочетается с CQRS и проектированием на основе предметной области, совокупные корни отвечают за проверку и применение команд (часто путем вызова методов их экземпляров из обработчика команд), а затем за публикацию событий. Это также основа, на которой совокупные корни основывают свою логику работы с вызовами методов. Следовательно, входные данные — это команда, а выходные данные — одно или несколько событий, которые сохраняются в хранилище событий, а затем часто публикуются в брокере сообщений для тех, кто заинтересован (например, представление приложения ).

Моделирование совокупных корней для выходных событий может изолировать внутреннее состояние даже дальше, чем при проектировании данных чтения из сущностей, как в стандартных n -уровневых архитектурах передачи данных. Одним из существенных преимуществ является то, что средства доказательства аксиоматических теорем (например, Microsoft Contracts и CHESS ^[10]) проще применять, так как совокупный корень полностью скрывает свое внутреннее состояние. События часто сохраняются на основе версии совокупного корневого экземпляра, что создает модель предметной области, которая синхронизируется в распределенных системах посредством оптимистического параллелизма .

Известные инструменты [ править ]

Хотя предметно-ориентированное проектирование не зависит от какого-либо конкретного инструмента или платформы, примечательные примеры включают в себя:

Actifsource — плагин для Eclipse , который позволяет разрабатывать программное обеспечение, сочетая DDD с проектированием на основе моделей и генерацией кода .
Context Mapper, предметно-ориентированный язык и инструменты для стратегического и тактического DDD. ^[11]
CubicWeb — семантическая веб-инфраструктура с открытым исходным кодом, полностью управляемая моделью данных. Директивы высокого уровня позволяют итеративно уточнять модель данных, выпуск за выпуском. Определить модель данных достаточно, чтобы получить работающее веб-приложение. Требуется дальнейшая работа, чтобы определить, как будут отображаться данные, когда представлений по умолчанию недостаточно.
OpenMDX — платформа MDA Framework с открытым исходным кодом на основе Java, поддерживающая Java SE , Java EE и .NET . OpenMDX отличается от типичных сред MDA тем, что «использует модели для непосредственного управления поведением операционных систем во время выполнения» .
Restful Objects — стандарт для сопоставления Restful API с объектной моделью предметной области (где объекты предметной области могут представлять сущности, модели представлений или сервисы). Две платформы с открытым исходным кодом (одна для Java, другая для .NET) могут автоматически создавать Restful Objects API из модели предметной области, используя отражение.

См. также [ править ]

Сетка данных — предметно-ориентированная архитектура данных.
Штурм событий
Представление знаний
Онтология (информатика)
Семантический анализ (представление знаний)
Семантические сети
Семантика
Модель С4
Строго типизированный идентификатор
Интегрированный дизайн
Системная наука

Ссылки [ править ]

^ Миллет, Скотт; Мелодия, Ник (2015). Шаблоны, принципы и практики предметно-ориентированного проектирования . Индианаполис: Wrox. ISBN 978-1-118-71470-6 .
^ Вернон, Вон (2013). Реализация предметно-ориентированного проектирования . Река Аппер-Сэдл, Нью-Джерси: Аддисон-Уэсли. п. 3. ISBN 978-0-321-83457-7 .
^ Доменно-ориентированное проектирование: решение проблем, лежащих в основе программного обеспечения . Аддисон-Уэсли Профессионал. 2003. ISBN 978-0321125217 .
^ Руководство по архитектуре приложений Microsoft, 2-е издание. Получено с http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .
^ Перейти обратно: ^а ^б Эванс, Эрик (22 августа 2003 г.). Доменно-ориентированное проектирование: решение проблем, лежащих в основе программного обеспечения . Бостон: Аддисон-Уэсли. ISBN 978-032-112521-7 . Проверено 12 августа 2012 г.
^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .
^ Хейвуд, Дэн (2009), Доменно-ориентированное проектирование с использованием голых объектов , Прагматичные программисты .
^ MDE можно рассматривать как расширенную версию MDA.
^ Кэбот, Хорди (11 сентября 2017 г.). «Сравнение предметно-ориентированного проектирования с модельно-ориентированным проектированием» . Языки моделирования . Проверено 5 августа 2021 г.
^ инструмент поиска ошибок MS
^ Стефан Капферер и Олаф Циммерманн: Проектирование доменно-ориентированных сервисов - контекстное моделирование, рефакторинг моделей и генерация контрактов, 14-й симпозиум и летняя школа по сервис-ориентированным вычислениям (SommerSoC 2020) [1]

Внешние ссылки [ править ]

Предметно-ориентированный дизайн, определения и краткое изложение шаблонов (PDF) , Эрик Эванс, 2015 г.
DDD Crew на GitHub : холст ограниченного контекста, совокупный холст, процесс моделирования и другие репозитории
Введение в предметно-ориентированное проектирование , методы и инструменты
Реализация совокупного корня на языке C#
Context Mapper: среда моделирования для стратегического проектирования на основе предметной области (инструмент, учебные пособия, примеры моделирования DDD)
Стратегическая деятельность DDC в репозитории практики проектирования (DPR) и тактическая деятельность DDC в репозитории практики проектирования (DPR)

[millet2015-1] Миллет, Скотт; Мелодия, Ник (2015). Шаблоны, принципы и практики предметно-ориентированного проектирования . Индианаполис: Wrox. ISBN 978-1-118-71470-6 .

[vernon2013-2] Вернон, Вон (2013). Реализация предметно-ориентированного проектирования . Река Аппер-Сэдл, Нью-Джерси: Аддисон-Уэсли. п. 3. ISBN 978-0-321-83457-7 .

[3] Доменно-ориентированное проектирование: решение проблем, лежащих в основе программного обеспечения . Аддисон-Уэсли Профессионал. 2003. ISBN 978-0321125217 .

[4] Руководство по архитектуре приложений Microsoft, 2-е издание. Получено с http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .

[evans2004-5] Перейти обратно: ^а ^б Эванс, Эрик (22 августа 2003 г.). Доменно-ориентированное проектирование: решение проблем, лежащих в основе программного обеспечения . Бостон: Аддисон-Уэсли. ISBN 978-032-112521-7 . Проверено 12 августа 2012 г.

[6] Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .

[book.haywood-7] Хейвуд, Дэн (2009), Доменно-ориентированное проектирование с использованием голых объектов , Прагматичные программисты .

[8] MDE можно рассматривать как расширенную версию MDA.

[9] Кэбот, Хорди (11 сентября 2017 г.). «Сравнение предметно-ориентированного проектирования с модельно-ориентированным проектированием» . Языки моделирования . Проверено 5 августа 2021 г.

[10] инструмент поиска ошибок MS

[11] Стефан Капферер и Олаф Циммерманн: Проектирование доменно-ориентированных сервисов - контекстное моделирование, рефакторинг моделей и генерация контрактов, 14-й симпозиум и летняя школа по сервис-ориентированным вычислениям (SommerSoC 2020) [1]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]