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

Тон или стиль этой статьи могут не отражать энциклопедический тон, используемый в Википедии . См. Рекомендации в руководстве Википедии по написанию лучших статей . ( Февраль 2020 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Доменно-ориентированный дизайн ( DDD ) - это концепция, согласно которой структура и язык программного кода (имена классов, методы классов, переменные класса) должны соответствовать бизнес-области . Например, если программное обеспечение обрабатывает заявки на получение ссуды, оно может иметь такие классы, как LoanApplication и Customer, и такие методы, как AcceptOffer и Withdraw.

DDD связывает реализацию с развивающейся моделью. ^[1]

Доменно-ориентированный дизайн преследует следующие цели:

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

Этот термин был введен Эриком Эвансом в одноименной книге. ^[2]

Концепции [ править ]

Концепции модели включают в себя:

Контекст

Обстановка, в которой появляется слово или высказывание, определяющая его значение;

Домен

Сфера знаний ( онтология ), влияния или деятельности. Предметная область, к которой пользователь применяет программу, является областью программного обеспечения;

Модель

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

Вездесущий язык

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

Стратегический предметно-ориентированный дизайн [ править ]

В идеале было бы предпочтительнее иметь единую унифицированную модель. ^{[ необходима цитата ]} Хотя это благородная цель, на самом деле она обычно фрагментируется на несколько моделей. Полезно признать этот факт жизни и работать с ним.

Стратегический дизайн - это набор принципов для поддержания целостности модели, выделения модели предметной области и работы с несколькими моделями. ^{[ необходима цитата ]}

Ограниченный контекст [ править ]

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

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

Непрерывная интеграция [ править ]

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

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

Контекстная карта [ править ]

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

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

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

Строительные блоки [ править ]

В книге Domain-Driven Design , ^[2] ряд концепций и практики на высоком уровня формулируется, например, повсеместный язык это означает , что модель предметной области должна сформировать общий язык , данный экспертами в предметной области для описания системных требований, которые одинаково хорошо работают для бизнес-пользователей или спонсоров и для разработчиков программного обеспечения. Книга очень сфокусирована на описании уровня предметной области как одного из общих уровней в объектно-ориентированной системе с многоуровневой архитектурой . В DDD есть артефакты для выражения, создания и извлечения моделей предметной области:

Юридическое лицо

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

Пример. Большинство авиакомпаний выделяют каждое место на каждом рейсе уникальным образом. В этом контексте каждое место является сущностью. Однако Southwest Airlines, EasyJet и Ryanair не различают места; все сиденья одинаковые. В этом контексте кресло фактически является объектом-ценностью.

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

Объект значения - это объект, который содержит атрибуты, но не имеет концептуальной идентичности. Их следует рассматривать как неизменяемые .

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

Совокупный

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

Пример: когда вы управляете автомобилем, вам не нужно беспокоиться о том, чтобы колеса двигались вперед, двигатель воспламенялся искрой и топливом и т. Д .; вы просто ведете машину. В этом контексте автомобиль представляет собой совокупность нескольких других объектов и служит совокупным корнем для всех других систем.

Событие домена

Объект домена, который определяет событие (то, что происходит). Событие предметной области - это событие, которое волнует экспертов предметной области.

Услуга

Когда операция концептуально не принадлежит какому-либо объекту. Следуя естественным контурам проблемы, вы можете реализовать эти операции в сервисах. См. Также Сервис (системная архитектура) .

Репозиторий

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

Фабрика

Методы создания объектов предметной области должны делегироваться специализированному объекту Factory , чтобы можно было легко заменить альтернативные реализации.

Недостатки [ править ]

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

Отношение к другим идеям [ править ]

Объектно-ориентированный анализ и дизайн

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

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

Хотя DDD совместим с модельным проектированием и архитектурой , соответственно, MDE / MDA ^[4]Смысл этих двух концепций несколько различается. MDA больше занимается средствами перевода модели в код для различных технологических платформ, чем практикой определения лучших моделей предметной области. Методы, предоставляемые MDE (для моделирования доменов, для создания DSL для облегчения связи между экспертами в предметной области и разработчиками, ...) облегчают применение DDD на практике и помогают практикам DDD получить больше от своих моделей. Благодаря методам преобразования модели и генерации кода в MDE модель предметной области можно использовать не только для представления предметной области, но и для создания реальной программной системы, которая будет использоваться для управления ею. На этом рисунке показано возможное представление сочетания DDD и MDE .

Обычные старые объекты Java и простые старые объекты CLR

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

Шаблон обнаженных объектов

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

Доменно-ориентированное моделирование

Доменно-ориентированное моделирование (DSM) - это DDD, применяемый с использованием предметно-ориентированных языков .

Доменный язык

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

Аспектно-ориентированное программирование

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

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

Разделение ответственности за запросы команд (CQRS) - это архитектурный шаблон для разделения операций чтения и записи, где первое является запросом, а второе - командой. Команды изменяют состояние и, следовательно, приблизительно эквивалентны вызову метода для совокупных корней / объектов. Запросы читают состояние, но не изменяют его. CQRS - это производный архитектурный шаблон от шаблона проектирования, называемого разделением команд и запросов (CQS), который был придуман Бертраном Мейером.. В то время как CQRS не требует DDD, доменная структура делает различие между командами и запросами явным, исходя из концепции совокупного корня. Идея состоит в том, что данный агрегированный корень имеет метод, соответствующий команде, а обработчик команд вызывает метод для агрегированного корня. Совокупный корень отвечает за выполнение логики операции и выдачу либо количества событий, либо отказа (исключение или перечисление / количество результатов выполнения) ИЛИ (если Event Sourcing (ES) не используется) просто изменяя свое состояние для постоянная реализация, такая как ORM для записи в хранилище данных, в то время как обработчик команд отвечает за решение проблем инфраструктуры, связанных с сохранением состояния или событий совокупного корня и созданием необходимых контекстов (например, транзакций).

Поиск событий

Event Sourcing (ES) - это архитектурный паттерн, который гарантирует, что ваши объекты (согласно определению Эрика Эванса ) отслеживают свое внутреннее состояние не посредством прямой сериализации или сопоставления O / R, а посредством чтения и фиксации событий для события. хранить. Если ES сочетается с CQRS и DDD, совокупные корни отвечают за тщательную проверку и применение команд (часто посредством вызова их методов экземпляра из обработчика команд), а затем публикацию одного или набора событий, которые также являются основой. на которых совокупные корни основывают свою логику для работы с вызовами методов. Следовательно, ввод - это команда, а вывод - одно или несколько событий, которые транзакционно (единичная фиксация) сохраняются в хранилище событий, а затем часто публикуются в брокере сообщений в интересах заинтересованных лиц (часто интересуют представления; они затем запрашиваются с помощью сообщений-запросов). При моделировании ваших совокупных корней для вывода событий вы можете изолировать внутреннее состояние даже дальше, чем это было бы возможно при проецировании считываемых данных из ваших сущностей,как это делается в стандартных n-уровневых архитектурах передачи данных. Одним из значительных преимуществ этого является то, что такие инструменты, как средства доказательства аксиоматических теорем (например, Microsoft Contracts и CHESS^[6] ) проще применять, поскольку совокупный корень полностью скрывает свое внутреннее состояние. События часто сохраняются на основе версии агрегированного корневого экземпляра, что дает модель предметной области, которая синхронизируется в распределенных системах на основе концепции оптимистичного параллелизма.

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

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

• Actifsource - это подключаемый модуль для Eclipse, который позволяет разрабатывать программное обеспечение, комбинируя DDD с проектированием на основе моделей и генерацией кода .
• CubicWeb - это фреймворк семантической сети с открытым исходным кодом, полностью управляемый моделью данных. Директивы высокого уровня позволяют итеративно уточнять модель данных, выпуск за выпуском. Определения модели данных достаточно, чтобы получить работающее веб-приложение. Требуется дополнительная работа, чтобы определить, как будут отображаться данные, когда представлений по умолчанию недостаточно.
• OpenMDX : открытый исходный код, на основе Java, MDA Framework с поддержкой Java SE , Java EE и .NET . OpenMDX отличается от типичных сред MDA тем, что «использует модели для непосредственного управления поведением операционных систем во время выполнения» .
• OpenXava : создает приложение AJAX из объектов JPA . Вам нужно только написать классы предметной области, чтобы получить готовое к использованию приложение.
• Restful Objects - это стандарт Restful API для объектной модели предметной области (где объекты предметной области могут представлять сущности, модели представления или службы). Две платформы с открытым исходным кодом (одна для Java, одна для .NET) могут автоматически создавать API Restful Objects из модели предметной области, используя отражение.

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

• Событие штурм
• Представление знаний
• Онтология (информатика)
• Семантический анализ (представление знаний)
• Семантические сети
• Семантика

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

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

• Доменно-ориентированный дизайн, определения и сводные данные по шаблонам (PDF) , Эрик Эванс, 2015 г.
• Реализация агрегированного корня на языке C #
• Введение в предметно-ориентированный дизайн , методы и инструменты