Относительно того, как это вписывается в DDD: я только недавно начал свое путешествие в DDD, но много слышно о разделении команд / запросов в этом круге. Конечно, если вы делаете что-то, что попадает в ваш домен (например, выборка для автозаполнения или, конечно, если вы разрешаете частичную отправку страницы для выполнения команды домена), вы должны решить, как это происходит и как домен структурирован для обработки.
Я думаю, что два решения наиболее актуальны.
Во-первых, биты, полностью находящиеся в браузере, и даже те, которые находятся конкретно на уровне вашего приложения, находятся за пределами вашего домена и, таким образом, хотя они и рассматриваются в многоуровневой архитектуре в разделе обсуждения DDD, они не попадают в сущность / значение / событие / службу, и т.д. обсуждение. Однако, если вы используете AJAX для взаимодействия со своим прикладным уровнем и, в свою очередь, хотите получить доступ к своему домену, вам необходимо еще раз подумать о двух вещах.
(a) Вы разделяете команды и запросы, просто используя разные методы в своем домене? Хорошо, если у вас относительно небольшая потребность в запросах или командах, и это не будет выглядеть как «шум» в вашем доменном API. В противном случае у вас есть отдельный ограниченный контекст ... другой домен, смоделированный только для запросов, которые необходимы вашему пользовательскому интерфейсу, чтобы избежать беспорядка в вашем домене. В любом случае, вы делаете что-то вроде обработчика JS-> AJAX на уровне приложения-> домен (включая службу домена).
(б) Это команда или запрос? Как только вы выяснили (а), это даст вам знать, где будет доступ ... затем используйте сценарий использования уровня презентации, чтобы разработать концепцию домена и перевести ее на ваш вездесущий язык.
Во-вторых, у вас есть DTO против прямого решения для домена. Это может быть тема сбора религиозной войны, но обычно ответ «зависит». Я думаю, что есть случаи для использования DTO и случаи для не (в пределах той же архитектуры) ... просто ищите все обсуждения по теме и применяйте шаблон только там, где это добавляет ценность; Я не буду пытаться освещать детали здесь.
Надеюсь, это обеспечит некоторую проницательность или, по крайней мере, магнит для разговора, к которому добавят другие.