在List或DropdownList,DDD中加载Value对象

Question

我需要澄清一些事情.

有人积极,2个VOs(国家,州政府).

我想在我的表示层中加载所有国家/地区(我正在使用mvc)

Evan说你只使用存储库(IPersonRepository)来处理root实体(它应该总是只返回对Aggregate Root的引用)

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

我通常做的是解决这个问题:

在IPersonRepository中添加此方法

IList<Country> LookupCountrysOfPerson();

在Infra层实现Domain接口,如下所示:

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

我的伙伴说错了.

有时您必须牺牲您的域模型才能完成某项任务

做这个的最好方式是什么？

请带代码!:)

Answer 1

我想说你不太可能需要国家成为一个实体.我怀疑这个国家只不过是参考数据,就像一个人的头衔一样.您域中的国家/地区是否存在任何关联行为？我怀疑这是印在字母/信封上的东西.

这个问题有点类似于我回答的这个问题:

我的建议是,您实现了一个客户端可以使用并且缓存的Lookup服务.忽略DDD的规则以及与此相关的聚合或存储库的任何事情.正如其他人提到的那样,这就是CQRS的意识形态发挥作用的地方; 客户端不应该通过域来获取数据.该域纯粹是事务性的,不是为查询而设计的.

本文解释了如何为通常填充UI中的下拉列表的事物(即标题,国家等)的参考数据构建通用查找服务

@Kamal - 很简单，您可以构建一个 UI 屏幕，允许用户根据需要配置其查找项目 - 它是可配置的数据。我开发的应用程序是为多个客户设计的，因此每个客户都可以选择自己的国家/地区列表。通常，安装应用程序时会安装默认列表 - 客户端随后可以对其进行配置。 (2认同)

Answer 2

埃文斯还说(第170页)"许多物体可能会使用像地点一样基本的实体,原因很多......"

出于上述原因,我还会考虑将国家设为实体.也许更重要的是,它是一个低级别的对象.您甚至可能通过配置而不是通过任何实际的域活动提供Country.因此,我会将其从Person中删除,并使其成为一个独立的实体.

此外,对于此类对象,您可能并不真正需要专用存储库,请考虑创建单个查找服务,该服务为一组此类性质的类似对象提供查询访问.