Question

我需要澄清一些事情。

让人激活，2个VO（国家，州政府）。

我想在我的演示文稿图层中加载所有国家/地区（我正在使用mvc）

Evan说你只使用存储库（IPersonRepository）来处理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下拉列表的内容（即标题，国家/地区等）的参考数据构建通用查找服务

Answer 2

埃文斯也说（第170页）“许多物品可能会使用基本定位的实体，原因很多......”

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

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

Answer 3

如果在你的域名国家/地区实际上是一个VO（你不想在国家名称中保持一个身份的线程被更改等）这是最常见的场景，我会在数据访问中添加一个专门的类图层将所有国家/地区的列表作为VO返回。我还将缓存（NHibernate中的二级缓存）添加到国家/地区实体并列出所有国家/地区查询，以便我不必每次都访问数据库。

实际上，这是CQRS真正闪耀的地方。 CQRS承认您不必通过域层来获取某些数据用于演示目的。在CQRS中，您只需获取一些数据。

Answer 4

听起来国家实际上并不是价值对象;它们具有不同的身份，对于Person对象之外的业务目的非常重要。它们应该成为实体，并以适合它们的方式对待。

以这种方式思考：让我们说一些不稳定的国家让他们现在的独裁者被推翻并改名。 Person对象对Country的引用应该仍然有效，因为Country不是由其属性（即表示其名称的字符串）定义的，而是由其标识定义。