在 DDD 中，域模型实体可以访问其存储库吗？答案

【问题标题】：In DDD, Is it ok for domain model entities have access to their repositories?在 DDD 中，域模型实体可以访问其存储库吗？
【发布时间】：2017-05-18 00:05:21
【问题描述】：

我目前正在使用Domain Driven Design 概念设计和实现一个框架。

我正在尝试将Validation 放在域模型层中。

有时做验证需要访问数据库并查询它，例如：

"querying to check multiple column unique index"

关于这一点以及查询应该写在存储库层类中的事实，领域实体需要在域模型层中引用它们的存储库接口，以便将验证完全放在域中模型层。

我想知道域实体是否可以访问存储库？

如果不行的话，这种情况应该怎么处理呢？

我的意思是应该将此类验证方法移至repository 或Application Service 层吗？如果是，是否可以将验证方法移至这些层？

或者由于域服务可以访问存储库，我们是否应该在 domain model layer 中创建 domain services 以进行验证？

我们应该如何处理？

提前致谢

【问题讨论】：

Is it ok for entities to access repositories?的可能重复
@guillaume31 我认为这与您提到的问题不同，我编辑了我的问题并添加了更多细节。任何解决方案将不胜感激！
您需要检查哪些不变量？我们在谈论哪个聚合根，为什么验证这种唯一性是它的责任？ “检查多列唯一索引”并不是一个域描述...
你的Q标题和我链接的Q一模一样
我正在尝试将验证放在域模型层中，以处理验证中有时可能发生的所有复杂性！例如，验证复杂的域服务（如生产线馈送），如果您知道的话，这是一个非常复杂的过程。检查唯一性只是需要查询的另一个条件。在这种情况下，您可能需要查询数据库，因此您需要访问它的存储库。

标签： architecture domain-driven-design ddd-repositories

【解决方案1】：

我想知道域实体是否可以访问存储库？

并非如此 - 它会在您的组件之间创建依赖关系。

架构期望是聚合在加载时具有保护其不变量所需的所有状态信息。修改聚合所涉及的任何其他状态都应作为参数传入。

因此，需要查询聚合边界之外的内容表明您的设计存在缺陷（您尝试强制执行的约束不是“真实的”，聚合边界绘制在错误的位置等） .

使用域服务来支持聚合需要的查询比直接连接到存储库要好，但也好不到哪里去。域模型应该与环境隔离，但引入域服务（或存储库）来支持验证会将域模型绑定到流程边界。

一个可以满足您需求的可接受的替代方法是让应用程序从存储库中获取必要的数据，然后将该数据的表示（或提供对该数据的访问的域服务）传递给聚合，这然后可以将其用于“验证”。

请注意，您有一个一致性问题 - 当您使用数据的陈旧副本“验证”您自己的更改时，其他一些聚合可能会更改远程数据。如果您的总边界是正确的，那么这里的不一致对业务的成本应该是“小”的。

关键要点是状态检索和状态验证是独立的关注点，并且了解聚合无法控制的任何状态必然是陈旧的 - 及时分离检索和验证不会为您的系统添加新的竞争条件.因此，将数据检索留在应用程序组件中，将验证放在聚合中，并接受您正在处理陈旧数据的权衡。

【讨论】：

非常感谢。如果使用构造函数注入将存储库实例从上面的层传递给域实体怎么办？就像它为域服务所做的那样。
@VoiceOfUnreason 我现在几乎有同样的问题。 AR 包含一个值对象集合，它是一个大集合，并且值对象也是一个大对象。但是值对象包含一个身份，所以我让 AR 持有值对象身份。 AR 实现了从标识集合中查找某个值对象标识的逻辑，并且还需要找到的值对象的详细信息，那么我该如何解决呢？
如果一个对象被任何其他组件注入，它在概念上失去了它作为领域模型的地位。让域模型直接访问其存储库可能很有趣，但不要这样做。领域模型实际上只关心自己的事情。