У меня проблемы с проведением четкой грани между уровнем представления и приложениями в дизайне, управляемом доменом.
Куда должны идти файлы Controllers, Views, Layouts, Javascript и CSS?
Это на уровне приложения или презентации?
И если они объединяются в одном слое, что содержит другой? Это пусто?
Ответы:
То, что кто-то создал и назвал «Уровень приложения» и «Уровень представления», не означает, что они должны быть в вашем приложении. Вы должны создавать слои ПОСЛЕ того, как вы создали значительный объем кода, который вы сгруппировали и хотите назвать эту группу для связи между разработчиками и ясности кода.
С точки зрения DDD. Уровень приложений - это все, что не является уровнем домена. Который включает в себя логику приложения, услуги представления и приложения.
Существует большая разница между уровнем приложений и уровнем представления с точки зрения DDD.
Хотя DDD сосредотачивается вокруг того, как моделировать домен, используя строительные блоки DDD и такие понятия, как ограниченный контекст, вездесущий язык и т. Д., По-прежнему жизненно важно четко идентифицировать и разделять различные уровни в вашем приложении.
Архитектура играет большую роль в реализации успешного приложения DDD. Известная архитектура, получившая много шумихи в последнее время, - это луковая архитектура:
В этом проекте уровень пользовательского интерфейса / представления и прикладной уровень четко разделены. Слияние двух вместе создает тесную связь между двумя слоями, которые имеют четкие отдельные проблемы и обязанности.
Уровень представления должен содержать только логику представления. Избегайте умных интерфейсов, которые знают слишком много. В основном это контроллеры и представления MVC в дополнение к CSS, JS, шаблонам, формам и всему, что относится к объектам ответа и запроса.
Действия, выполняемые через представление, делегируются на прикладной уровень через команды. Прикладной уровень содержит логику приложения. Это обычно отображается в случае использования. Он содержит ЧТО система должна сделать, чтобы удовлетворить сценарий использования. Типичная служба приложений запрашивает у хранилища агрегат, а затем вызывает действие для этого агрегата.
Взгляните на пример проекта из IDDD Вона Вернона
entry pointи где composition rootразмещены? Я всегда думал, что это была ответственность Applicationслоя. Но теперь, похоже, это Presentationслой.
Дизайн, управляемый доменом, не имеет ничего общего ни с уровнем представления, ни с уровнем приложения. DDD - это методология, основное внимание в которой уделяется уровню домена. Таким образом, DDD не накладывает никаких ограничений в отношении любого другого уровня, за исключением уровня домена, и ваш вопрос также может быть задан в контексте любой другой методологии.
При этом очень распространено использование четырехслойной архитектуры для приложений DDD. Вот пример одного такого приложения, показывающего слои и их предполагаемое использование: Архитектура DDDSample . Таким образом, если вы решите использовать эту архитектуру, ваши представления и макеты перейдут на уровень интерфейсов, а контроллеры, если они не зависят от интерфейса, перейдут на уровень приложений.
С тем же успехом вы можете выбрать любую другую архитектуру, поскольку я сказал, что DDD не накладывает ограничений. Существует множество сред MVC, которые имеют различную структуру и могут также использоваться для приложений DDD. Тогда, конечно, вы разместите Ваши взгляды и макеты соответственно.