Загрузка объекта Value в List или DropdownList, DDD

Question

Мне нужно кое-что уточнить.

У Аггриагата, 2 Голосования (Страна, Государственная Провинция).

Я хочу загрузить всю страну в моем слое презентации (я использую mvc)

Эван говорит, что вы используете репозиторий (IPersonRepository) только для работы с корневым объектом (он всегда должен возвращать только ссылку на Aggregate Root)

   public interface IPersonRepository()
   {
     void savePerson(Person p);
     void removePerson(Person p);
     Ilist<Person> getPerson();
   }

что я обычно делаю, чтобы решить эту проблему:

Добавить в IPersonRepository этот метод

IList<Country> LookupCountrysOfPerson();

На уровне Infra реализуйте доменные интерфейсы следующим образом:

public IList<Person> LookupCountrysOfPerson()
{
    return Session.CreateQuery("from Countrys").List<Person>());
}

Мой партнер говорит, что я неправ.

Иногда вам приходится жертвовать моделью своего домена, чтобы выполнить какую-то задачу

Каков наилучший способ сделать это?

с кодом, пожалуйста! :)

Answer 1

Я бы сказал, что маловероятно, что вам нужна страна, чтобы быть субъектом. Я подозреваю, что страна - не что иное как справочные данные, очень как название человека. Есть ли какое-либо поведение в вашей стране Я подозреваю, что это именно то, что напечатано на письмах / конвертах.

Этот вопрос чем-то похож на тот, на который я недавно ответил:

Простой сводный вопрос о корне и хранилище

Мое предложение состоит в том, чтобы вы внедрили службу Lookup, которую ваш клиент может использовать и которая кэшируется. Игнорируйте правила DDD и все, что связано с агрегатами или репозиториями для этого. Как уже упоминал кто-то, именно здесь вступает в игру идеология CQRS; клиент не должен пройти через домен, чтобы получить данные. Домен чисто транзакционный, не предназначен для запросов.

В этой статье объясняется, как создать универсальный сервис поиска для справочных данных для вещей, которые обычно заполняют раскрывающиеся списки в пользовательском интерфейсе (т. Е. Название, страна и т. Д.)

http://wtfperminute.blogspot.com/2011/02/working-with-reference-data-lookups.html

Answer 2

Эванс также говорит (стр. 170): «Базовая сущность, такая как Местоположение, может использоваться многими объектами по многим причинам ...»

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

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

Answer 3

Если в вашей доменной стране фактически есть VO (вы не хотите поддерживать поток идентификаторов в названии страны, который был изменен и т. Д.), Что является наиболее распространенным сценарием, я бы добавил специализированный класс в доступе к данным слой, чтобы вернуть список всех стран в качестве ВО. Я также добавил бы кеширование (кэш 2-го уровня в NHibernate) к сущности страны и перечислил бы все запросы стран, чтобы мне не приходилось каждый раз обращаться к БД.

На самом деле, именно здесь CQRS действительно сияет. CQRS признает, что вам не нужно проходить через уровень домена, чтобы получить некоторые данные для целей презентации. В CQRS вы просто получаете некоторые данные.

Answer 4

Похоже, что страны на самом деле не являются объектами ценностей здесь; они имеют различную идентичность и важны для деловых целей за пределами ваших Person объектов. Они должны стать сущностями и относиться к ним соответствующим образом.

Подумайте об этом так: допустим, в какой-то нестабильной стране свергли нынешнего диктатора и сменили имя. Ссылка объекта Person на Country все еще должна быть действительной, потому что Country определяется не его атрибутами (то есть строкой, обозначающей его имя), а его идентичностью.