Презентация VS Прикладной уровень в DDD

9

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

Куда должны идти файлы Controllers, Views, Layouts, Javascript и CSS?

Это на уровне приложения или презентации?

И если они объединяются в одном слое, что содержит другой? Это пусто?

architecture domain-driven-design layers Матье Наполи
источник

Ответы:

7

То, что кто-то создал и назвал «Уровень приложения» и «Уровень представления», не означает, что они должны быть в вашем приложении. Вы должны создавать слои ПОСЛЕ того, как вы создали значительный объем кода, который вы сгруппировали и хотите назвать эту группу для связи между разработчиками и ясности кода.

С точки зрения DDD. Уровень приложений - это все, что не является уровнем домена. Который включает в себя логику приложения, услуги представления и приложения.

Euphoric
источник
2
Спасибо, действительно, вы заставили меня понять, что для моего случая разделение Приложения и Презентации бесполезно. Простота в первую очередь!
Матье Наполи
Если DDD имеет REST API вместо пользовательского интерфейса на уровне представления, REST API будет приложением или уровнем представления. Сейчас я в замешательстве, так как был уверен, что REST API - это уровень представления ..
Дарио Гранич
8
На самом деле, DDD предписывает четыре уровня в следующем порядке, от высшего к низшему: презентация, приложение, домен, инфраструктура. Таким образом, прикладной уровень не включает «представление». Кроме того, всегда полезно выбирать слои до того, как будет написано значительное количество кода, поскольку речь идет не только о группировании кода, но и об ограничении направления зависимостей во время компиляции.
Рожерио
11

Существует большая разница между уровнем приложений и уровнем представления с точки зрения DDD.

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

Архитектура играет большую роль в реализации успешного приложения DDD. Известная архитектура, получившая много шумихи в последнее время, - это луковая архитектура:

введите описание изображения здесь

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

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

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

Взгляните на пример проекта из IDDD Вона Вернона

Songo
источник
2
+1. Вот как я реализовал свой проект. Сразу же я смог сделать успехи. Поскольку я абстрагировался до уровня приложения, у меня было несколько уровней представления. Например, наш веб-интерфейс API и наш веб-сайт используют уровень приложения, который сэкономил много времени и дублировал код, поскольку моему веб-приложению не нужно создавать кадры для обмена сообщениями с веб-интерфейсом и из него, и он синхронизирует всю логику между двумя.
Синастетик
Где entry pointи где composition rootразмещены? Я всегда думал, что это была ответственность Applicationслоя. Но теперь, похоже, это Presentationслой.
Denis535
2

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

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

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

zafarkhaja
источник