Я применяю DDD для M-части моего MVC и после некоторых исследований (изучение up!), я пришел к пониманию, что мне нужно, чтобы мой контроллер взаимодействовал с услугами домена (в модели). Это сделает мой контроллер потребителем услуг домена и, следовательно, сервисом приложения (в условиях DDD). Это точно? Есть ли разница между контроллером и тем, что DD определяет как приложение?
Является ли Контроллер в MVC рассматриваемой службой приложений для DDD?
Ответ 1
Контроллер не считается сервисом в DDD. Контроллеры работают на уровне UI. Службы приложений получают данные из БД, проверяют данные, передают данные клиенту (MVC может быть клиентом, но так же может быть запрос из приложения winforms) и т.д.
Все, что делает контроллер, это обслуживание запросов от пользовательского интерфейса. Это не часть области приложения.
Ответ 2
Прикладной уровень находится где-то между уровнем домена и уровнем представления. Контроллер является частью уровня представления, отправляет команды или запросы на уровень приложений, где сервисы приложений выполняют их, используя сервисы и объекты модели домена. Таким образом, контроллеры отличаются от служб приложений, и они, вероятно, связаны с реальной формой связи, например, HTTP. Не следует вызывать доменные службы напрямую из контроллеров, это может быть признаком неулокального кода.
Конструкция, управляемая доменом: служба домена, служба приложения
- Доменные службы: инкапсулирует бизнес-логику, которая не вписывается в доменный объект и НЕ является типичной операцией CRUD. они будут принадлежать хранилищу.
- Службы приложений: используются внешними потребителями для связи с вашей системой (например, веб-службы). Если потребителям нужен доступ к CRUD операции, они будут выставлены здесь.
Таким образом, ваша служба, вероятно, является службой приложений, а не службой домена или некоторыми службами приложений, какой-то службой домена. Вы должны проверить и реорганизовать свой код. Я думаю, через 4 года это не имеет значения, но у меня были те же мысли о приложении, которое я сейчас разрабатываю. Это приложение может быть слишком маленьким, чтобы использовать на нем DDD, поэтому путание контроллеров со службами приложений является признаком чрезмерного повышения квалификации.
Это интересный вопрос, когда начать добавлять больше слоев. Я думаю, что каждое приложение должно начинаться с некоторой доменной модели и адаптеров для подключения к этой доменной модели. Так что, если приложение достаточно простое, добавление более двух слоев может не потребоваться. Но это всего лишь мысль, я не настолько опытен с DDD.
Ответ 3
Слоистая архитектура разбивает приложение на уровень пользовательского интерфейса, уровня приложения, уровня домена и инфраструктуры (Vaugn Vernons, реализующий проект, управляемый доменами (местоположение 2901)). Контроллер попадает в "Application Layer" этой более широкой архитектуры дизайна и поэтому будет напрямую взаимодействовать с сервисами домена в модели и считается сервисом приложения. Мало того, очевидно, что он также будет использовать сущности и агрегаты как доступные.
Ответ 4
В DDD Reference контроллеры вообще не упоминаются. Поэтому я думаю, что от DDD POV ответ не определен. Поэтому я хотел бы рассмотреть более практический вопрос: "Нужно ли разделять контроллеры и службу приложений"?
Плюсы:
- Отделение обработки ввода от реализации варианта использования.
Минусы:
- Дополнительный уровень косвенности, который усложняет понимание более простых случаев. (Также раздражает реализация какой-то тривиальной вещи, вытягивая данные через множество слоев без каких-либо действий).
Поэтому я бы выбрал разделение контроллера и службы приложения, если обработка ввода скрывает логику прецедента. Я бы предпочел сохранить логику прецедента в контроллере, если оба достаточно просты, чтобы вы могли легко видеть в прецедентах кода отдельно от обработки ввода.