поиск ресурсов для построения сущности в DDD

Я новичок в DDD, и вот моя дилемма:

Я должен сохранить сущность A, которая имеет ссылку на сущность B (давайте рассмотрим, что обе являются корнями сущностей). Слой пользовательского интерфейса собирает всю эту информацию (в контроллере) через A_DTO (класс DTO для A), сопоставляет атрибуты с новым экземпляром A из DTO, теперь для ссылки на B в A пользовательский интерфейс отправляет идентификатор. Поскольку я использую ORM для репозиториев, я хотел бы найти экземпляр объекта B из BRepository, заполнить ссылку на новый экземпляр A, который мы создаем, и, наконец, вызвать ARepository.save (экземпляр A).

У меня есть несколько вариантов

  1. Сделайте все это на уровне пользовательского интерфейса (либо в контроллере, либо в каком-либо фасаде службы) или
  2. Сделайте это в ApplicationService с именем createA или даже в доменной службе.

Какой из вариантов будет правильным ?? Здесь действительно выделяется процесс поиска B по его идентификатору, чтобы получить ссылку для установки на объект A, это можно в равной степени аргументировать как процесс, обеспечивающий удовлетворение ORM или согласованность модели предметной области. В процессе установки ссылки B на A могут быть неявные бизнес-правила и проверки, которые, я думаю, являются движущими моментами для принятия решения.

Кроме того, то, что может вызвать странность в дальнейшем, здесь будет рассматриваться для проверки, если проверки будут вплетены в процесс создания объекта и скажут, что конструкторы и / или установщики через определенные ошибки, которые могут быть переданы клиенту через пользовательский интерфейс и имеют еще один уровень валидатинов через репозиторий ?? или как явный шаг, происходящий в контроллерах ??


domain-driven-design ddd-repositories
person redzedi    schedule 22.07.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

DTO - это просто удобный класс для передачи данных на уровне пользовательского интерфейса. Тот факт, что вы используете идентификатор для ссылки на B, является деталью реализации уровня пользовательского интерфейса. Таким образом, задачей уровня / контроллера пользовательского интерфейса должно быть отображение DTO на объект домена, включая преобразование идентификаторов в ссылки.

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

person casablanca    schedule 23.07.2012

arrow_upward
0
arrow_downward

Оба варианта можно рассматривать как правильные, но я предпочитаю вариант 2, потому что инкапсуляция, предоставляемая службами приложений, помогает читать и понимать код. Это также упрощает консолидацию API вашего домена. Аргумент в пользу варианта 1 вместо 2 заключается в том, что дополнительный уровень инкапсуляции, возникающий в результате использования служб приложений, представляет собой ненужную сложность, хотя, конечно, судить вы. Проверка обычно проявляется на нескольких уровнях приложения, включая уровень представления и уровень домена. Кажется идеальным написать логику проверки один раз и повторно использовать ее повсюду, на практике обычно проще продублировать логику проверки. Это означает, что уровень представления, такой как ASP.NET MVC, имеет собственные декларации проверки для моделей представления. Затем сущности службы приложения и домена также должны выполнить любую проверку, которая необходима в этом контексте. Взгляните на мои сообщения об услугах в DDD, а также валидацию в DDD для более подробного обсуждения этих тем.

person eulerfx    schedule 22.07.2012
comment
Большое спасибо за эти ссылки! - person redzedi; 23.07.2012