Доменно-ориентированный дизайн (DDD ) - это концепция, в которой структура и язык программный код (имена классов, методы классов, переменные класса) должен соответствовать бизнес-области. Например, если программное обеспечение обрабатывает заявки на получение ссуды, оно может иметь такие классы, как LoanApplication и Customer, и такие методы, как AcceptOffer и Withdraw.
DDD связывает реализацию с развивающейся моделью.
Доменно-ориентированное проектирование основано на следующих целях:
- сосредоточение основного внимания проекта на ядре домен и логика предметной области;
- создание сложных проектов на основе модели предметной области;
- начало творческого сотрудничества между техническими специалистами и экспертами в предметной области для итеративного уточнения концептуальная модель, которая обращается к конкретным проблемам предметной области.
Термин был введен в употребление в его одноименной книге.
Содержание
- 1 Концепции
- 2 Стратегический предметно-ориентированный дизайн
- 2.1 Ограниченный контекст
- 2.2 Непрерывная интеграция
- 2.3 Контекстная карта
- 3 Строительные блоки
- 4 Недостатки
- 5 Связь с другими идеями
- 6 Известные инструменты
- 7 См. Также
- 8 Ссылки
- 9 Внешние ссылки
Концепции
Концепции модели включают:
- Контекст
- Настройка, в которой появляется слово или утверждение, определяющее его значение;
- Домен
- Сфера знаний (онтоло gy ), влияние или активность. Предметная область, к которой пользователь применяет программу, является областью программного обеспечения;
- Модель
- Система абстракций, которая описывает выбранные аспекты области и может использоваться для решения проблем, связанных с этот домен;
- Универсальный язык
- Язык, структурированный вокруг модели предметной области и используемый всеми членами группы для связи всей деятельности группы с программным обеспечением.
Стратегический предметно-ориентированный дизайн
Семантическая сеть шаблонов в стратегическом предметно-ориентированном дизайне.
В идеале, было бы предпочтительнее иметь единую унифицированную модель. Хотя это благородная цель, на самом деле она обычно распадается на несколько моделей. Полезно признать этот факт жизни и работать с ним.
Стратегический дизайн - это набор принципов для поддержания целостности модели, выделения модели предметной области и работы с несколькими моделями.
Ограниченный контекст
В любом большой проект. Тем не менее, когда код, основанный на различных моделях, объединяется, программное обеспечение становится неполноценным, ненадежным и трудным для понимания. Общение между членами команды становится запутанным. Часто неясно, в каком контексте модель не должна применяться.
Следовательно, : явно определить контекст, в котором применяется модель. Явно устанавливайте границы с точки зрения организации группы, использования в определенных частях приложения и физических проявлений, таких как базы кода и схемы баз данных. Соблюдайте строгую согласованность модели в этих пределах, но не отвлекайтесь и не запутайтесь на внешние и внутренние проблемы.
Непрерывная интеграция
Когда несколько человек работают в одном и том же ограниченном контексте, существует сильная тенденция к фрагментации модели. Чем больше команда, тем серьезнее проблема, но всего три-четыре человека могут столкнуться с серьезными проблемами. Однако при разбиении системы на все более мелкие контексты в конечном итоге теряется ценный уровень интеграции и согласованности.
Поэтому : часто внедряйте процесс слияния всего кода и других артефактов реализации с автоматическими тестами для быстрого выявления фрагментации. Неустанно используйте вездесущий язык, чтобы выработать общий взгляд на модель по мере того, как концепции развиваются в головах разных людей.
Контекстная карта
Индивидуальный ограниченный контекст оставляет некоторые проблемы в отсутствие глобального представления. Контекст других моделей все еще может быть расплывчатым и изменчивым.
Люди в других командах не очень хорошо осведомлены о границах контекста и будут бессознательно вносить изменения, которые стирают границы или усложняют взаимосвязи. Когда необходимо установить связи между разными контекстами, они, как правило, перетекают друг в друга.
Следовательно, : Определите каждую модель, задействованную в проекте, и определите ее ограниченный контекст. Сюда входят неявные модели не объектно-ориентированных подсистем. Назовите каждый ограниченный контекст и сделайте имена частью повсеместного языка. Опишите точки соприкосновения между моделями, выделив явный перевод для любого общения и выделив любое совместное использование. Составьте карту существующей местности.
Строительные блоки
В книге Domain-Driven Design сформулирован ряд высокоуровневых концепций и практик, таких как вездесущий язык, означающий, что модель предметной области должна формировать общий язык, задаваемый эксперты в предметной области для описания системных требований, которые одинаково хорошо работают как для бизнес-пользователей или спонсоров, так и для разработчиков программного обеспечения. Книга очень сфокусирована на описании уровня домена как одного из общих слоев в объектно-ориентированной системе с многоуровневой архитектурой. В DDD существуют артефакты для выражения, создания и извлечения моделей предметной области:
- Entity
- Объект, который определяется не его атрибутами, а скорее потоком непрерывности и его идентичностью.
- Пример : Большинство авиакомпаний выделяют каждое место на каждом рейсе уникальным образом. В этом контексте каждое место является сущностью. Однако Southwest Airlines, EasyJet и Ryanair не различают места; все сиденья одинаковые. В этом контексте место на самом деле является объектом значения.
- Объект значения
- Объект, который содержит атрибуты, но не имеет концептуальной идентичности. Их следует рассматривать как неизменяемые.
- Пример. Когда люди обмениваются визитными карточками, они обычно не различают каждую уникальную карточку; их интересует только информация, напечатанная на карте. В этом контексте визитные карточки являются объектами-значениями.
- Агрегат
- Коллекция объектов, связанных вместе корневой сущностью, иначе известной как. Корень агрегата гарантирует согласованность изменений, вносимых внутри агрегата, запрещая внешним объектам хранить ссылки на его элементы.
- Пример: когда вы ведете машину, вам не нужно беспокоиться о перемещении колес вперед, воспламенение двигателя искрой и топливом и т. д.; вы просто ведете машину. В этом контексте автомобиль представляет собой совокупность нескольких других объектов и служит совокупным корнем для всех других систем.
- Событие домена
- Объект домена, который определяет событие (то, что бывает). Событие предметной области - это событие, о котором заботятся специалисты предметной области.
- Сервис
- Когда операция концептуально не принадлежит ни одному объекту. Следуя естественным контурам проблемы, вы можете реализовать эти операции в сервисах. См. Также Служба (архитектура системы).
- Репозиторий
- Методы получения объектов домена должны делегироваться специализированному объекту Репозитория, чтобы можно было легко менять альтернативные реализации хранилища.
- Завод
- Методы создания объектов предметной области должны делегироваться специализированному объекту Factory, чтобы можно было легко заменять альтернативные реализации.
Недостатки
Чтобы помочь поддерживать модель как чистая и полезная языковая конструкция, команда обычно должна реализовать большую часть изоляции и инкапсуляции в рамках модели предметной области. Следовательно, система, основанная на доменно-ориентированном дизайне, может иметь относительно высокую стоимость. Хотя предметно-ориентированный дизайн обеспечивает множество технических преимуществ, таких как ремонтопригодность, Microsoft рекомендует применять его только к сложным доменам, где модель и лингвистические процессы обеспечивают очевидные преимущества в передаче сложной информации и в формулировании общего понимания
Связь с другими идеями
- Объектно-ориентированный анализ и дизайн
- Хотя теоретически общая идея DDD не должна ограничиваться объектно-ориентированными подходами, на практике DDD стремится к использовать преимущества объектно-ориентированной техники. К ним относятся сущности / агрегированные корни в качестве получателей вызовов команд / методов и инкапсуляция состояния в пределах основных агрегированных корней и на более высоком архитектурном уровне, в ограниченных контекстах.
- Конструирование на основе модели (MDE) и Модель управляемая архитектура (MDA)
- Хотя DDD совместим с MDA / MDE (где MDE можно рассматривать как надмножество MDA ), цели этих двух концепций несколько различаются. MDA больше интересуется средствами перевода модели в код для различных технологических платформ, чем практикой определения лучших моделей предметной области. Методы, предоставляемые MDE (для моделирования доменов, для создания DSL для облегчения связи между экспертами в предметной области и разработчиками,...) облегчают применение DDD на практике и помогают практикам DDD получить больше от своих моделей. Благодаря методам преобразования модели и генерации кода MDE, модель предметной области можно использовать не только для представления предметной области, но и для создания реальной программной системы, которая будет использоваться для управления ею. На этом рисунке показано возможное представление объединенных DDD и MDE.
- Обычных старых объектов Java (POJO) и Обычных старых объектов CLR (POCO)
- POJO и POCO. являются концепциями технической реализации, характерными для Java и .NET Framework соответственно. Однако появление терминов POJO и POCO отражает растущее мнение о том, что в контексте любой из этих технических платформ объекты домена должны определяться исключительно для реализации бизнес-поведения соответствующей концепции домена, а не определяться требованиями. более конкретной технологической структуры.
- голые объекты шаблон
- Исходя из предпосылки, что если у вас есть достаточно хорошая модель предметной области, пользовательский интерфейс может быть просто отражение этой модели предметной области; и что если вам требуется, чтобы пользовательский интерфейс был прямым отражением модели предметной области, это потребует разработки более совершенной модели предметной области.
- Доменно-ориентированное моделирование (DSM)
- DSM - это DDD, применяемый посредством использования доменных языков.
- доменных языков (DSL)
- DDD специально не требует использования DSL, хотя его можно использовать для помощи определить DSL и такие методы поддержки, как многомодельное моделирование для конкретной области.
- Аспектно-ориентированное программирование (AOP)
- AOP позволяет легко исключить технические проблемы (такие как безопасность, управление транзакциями, ведение журнала) из модели предметной области и, как таковая, упрощает разработку и реализацию моделей предметной области, ориентированных исключительно на бизнес-логику.
- Разделение ответственности за запросы команд (CQRS)
- CQRS - это архитектурный шаблон для разделения чтения и записи, где первое - это запрос, а второе - команда. Команды изменяют состояние и, следовательно, приблизительно эквивалентны вызову метода для совокупных корней / объектов. Запросы читают состояние, но не изменяют его. CQRS является производным архитектурным шаблоном от шаблона проектирования, называемого разделением команд и запросов (CQS), который был придуман Бертраном Мейером. В то время как CQRS не требует DDD, доменно-ориентированный дизайн делает четкое различие между командами и запросами вокруг концепции агрегированного корня. Идея состоит в том, что данный агрегированный корень имеет метод, соответствующий команде, а обработчик команд вызывает метод для агрегированного корня. Совокупный корень отвечает за выполнение логики операции и выдачу либо количества событий, либо отказа (исключение или перечисление / количество результатов выполнения), ИЛИ (если источник событий (ES) не используется), просто изменяя его состояние для постоянная реализация, такая как ORM для записи в хранилище данных, в то время как обработчик команд отвечает за решение проблем инфраструктуры, связанных с сохранением состояния или событий совокупного корня и созданием необходимых контекстов (например, транзакций).
- (ES)
- Архитектурный шаблон, который гарантирует, что ваши сущности (согласно определению) отслеживают свое внутреннее состояние не посредством прямой сериализации или сопоставления O / R, а посредством чтения и фиксации событий в хранилище событий. Если ES сочетается с CQRS и DDD, совокупные корни несут ответственность за тщательную проверку и применение команд (часто посредством вызова их методов экземпляра из обработчика команд), а затем за публикацию одного или набора событий, которые также являются основой для которые совокупные корни основывают свою логику для работы с вызовами методов. Следовательно, ввод - это команда, а вывод - одно или несколько событий, которые транзакционно (одиночная фиксация) сохраняются в хранилище событий, а затем часто публикуются в брокере сообщений в интересах заинтересованных лиц (часто интересуют представления; они затем запрашиваются с помощью сообщений-запросов). При моделировании совокупных корней для вывода событий вы можете изолировать внутреннее состояние даже дальше, чем это было бы возможно при проецировании считываемых данных из ваших сущностей, как это делается в стандартных n-уровневых архитектурах передачи данных. Одним из значительных преимуществ этого является то, что такие инструменты, как средства доказательства аксиоматических теорем (например, Microsoft Contracts и CHESS), легче применять, поскольку совокупный корень полностью скрывает свое внутреннее состояние. События часто сохраняются на основе версии агрегированного корневого экземпляра, что дает модель предметной области, которая синхронизируется в распределенных системах на основе концепции оптимистичного параллелизма.
Известные инструменты
Практика 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) могут автоматически создавать Restful Objects API из модели предметной области, используя отражение.
См. Также
Ссылки
Внешние ссылки
Семантическая сеть шаблонов в стратегическом предметно-ориентированном дизайне. 