В Domain-Driven Design вы можете использовать доменные объекты в вашем пользовательском интерфейсе?

Question

Во многих ведущих проектах DDD, особенно в стиле MVC, я вижу, что пользовательский интерфейс использует экранные объекты, которые отражают сущности домена, а не напрямую используют эти объекты домена. Этот стиль, очевидно, предназначен для разделения и разделения интересов, и я лично предпочитаю этот стиль.

Но я не уверен, является ли это строгим принципом DDD, или это просто интерпретация его другими разработчиками.

Можете ли вы использовать свои доменные объекты непосредственно в пользовательском интерфейсе и при этом продолжать следовать методологии DDD в этом действии?

Или лучше использовать DDD, чтобы всегда использовать экранные объекты?

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

Answer 1

Я действительно не начинал понимать, почему или как вы будете отделять модель предметной области от проблем презентации, пока я не начал следить за работой Грега Янга и Уди Даана (через Мартина Фаулера).

Они обучают принципу, известному как Разделение ответственности за команды и запросы (CQRS).

Моя интерпретация CQRS заключается в том, что есть два набора обязанностей, которые могут тянуть модель предметной области в разных направлениях, что приводит к модели, которая выполняет посредственную работу с обоими. Двумя обязанностями являются команды (то есть поведение, которое может вызвать запись в базу данных) и запросы (то есть чтение из базы данных для извлечения данных для использования пользовательского интерфейса). Примером может быть добавление геттеров и сеттеров к вашим сущностям для поддержки привязки данных в пользовательском интерфейсе. Если в вашей модели есть геттеры и сеттеры, она, вероятно, плохо справится с моделированием изменений состояния, которые должны происходить транзакционно или инкапсулировать бизнес-логику. Он также не сможет моделировать бизнес-контекст изменений состояния (см. Event Sourcing).

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

Решение, предписанное CQRS, заключается в создании одной модели для команд, а другой - для запросов. Если ваша текущая модель имеет методы для изменения состояния (то есть поведения в модели) и методы получения, которые представляют состояние для пользовательского интерфейса для привязки данных, вы бы реорганизовали эти две обязанности в отдельные модели для команд и запросов. Модель запроса будет отображаться не на ваши доменные объекты, а непосредственно на базу данных. Если ваша база данных не захватывает производное состояние из вашей доменной модели, проверьте шаблон под названием Eager Read Derivation .

Если ваша система просто CRUD и не имеет поведения, попробуйте систему скаффолдинга, которая может быть автоматически построена из вашей схемы базы данных, например ASP.NET Dynamic Data

Answer 2

Если вы делаете шаблон MVC, вам нужны объекты просмотра; DDD это просто ваша модель. Это не значит, что вы должны всегда использовать MVC; DDD может быть построен, скажем, как симулятор, где все, на что вы смотрите, - это отправленные сообщения журнала. Но в MVC у вас действительно должны быть отдельные объекты вида.

Теперь спросите себя, почему это будет? Ответ в том, что представление может измениться, даже если бизнес-модель не . Модель DDD должна выражать, с точки зрения бизнеса, то, что важно для бизнеса.

Answer 3

DDD - это способ мышления при разработке программного обеспечения, которое начинается с моделирования домена. Как говорит веб-страница :

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

Одна вещь, которая естественным образом следует из этого шаблона проектирования, - это многоуровневая архитектура. Как сказано в Сводке DDD Pattern

Разбиение сложной программы на СЛОИ. Разработка дизайна в каждом СЛОЙ, который является связным и зависит только от слоев ниже. Следуйте стандартным архитектурным образцам обеспечить слабую связь с слоями выше. Сконцентрируйте весь код связанные с моделью предметной области в одном слой и изолировать его от пользователя интерфейс, приложение и код инфраструктуры. Домен объекты, свободные от ответственности показ себя, хранение сами, управляющие приложением задачи и т. д. могут быть сосредоточены на выражая модель предметной области. это позволяет модели развиваться, чтобы быть богатым достаточно и достаточно ясно, чтобы захватить необходимые знания бизнеса и положить это на работу.

Нужно ли вам иметь экранные объекты для этого? Это всего лишь один из способов реализации этого, но, возможно, даже не лучший способ обеспечить слабую связь. Что касается примера: может быть, слой представления - это всего лишь веб-браузер и файлы xlt для визуализации файлов XML, излучаемых бизнес-уровнем? Если у кого-то есть более подходящие примеры, пожалуйста, добавьте их. Я хочу сказать, что DDD подчеркивает многоуровневую архитектуру, но не ограничивает это одним возможным решением.

Answer 4

В дизайне MVC вы, как правило, имеете отображение из репозитория -> Модели домена, а затем из Модели домена -> Просмотр моделей. Хотя модели просмотра часто содержат доменные объекты.

Answer 5

Ответ довольно прямой:

• Доменные объекты имеют доменно-ориентированный дизайн и методы.
• Объекты вида имеют дизайн и методы, ориентированные на представление / управление.

Если вы можете использовать ваши доменные объекты в представлении, возможно, они не совсем ориентированы на домен.

Answer 6

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