design-patterns - 是否可以绕过复杂查询的存储库模式？

Question

这是我目前对 DDD 的理解:

严格的存储库模式应该只实现 get()、delete() 和 create()，也许还有 get() 的变体，人们可以在其中搜索或检索整个集合

每个聚合根通常都有一个存储库

(根据研究，我知道这些不是普遍接受的规范)

这里的问题是如何实现涉及许多聚合根的复杂查询。例如，我们有两个聚合根 - 产品和用户。如果我正在做一个列出用户购买了哪些产品的页面，那么我有一个跨越用户聚合和产品聚合的查询。

这个查询应该如何实现？

我现在正在做的实际上是为此查询和具有相关功能的查询建立一个存储库(有些人会不同意并说存储库不是查询层)。

仅使用产品和用户的存储库，获取所有记录并在内存中执行所有操作(这听起来不对)

让查询(LINQ 或 SQL)位于服务内部，根本不使用与聚合关联的存储库。

还有其他一些方法吗？

Answer 1

The strict repository pattern should only implement get(), delete() and create(), and maybe variants of get() where one can search or to retrieve an entire collection

存储库接口(interface)是您的域的一部分，应基于 Ubiquitous Language越多越好。所有存储库都不同，就像您的所有聚合不同一样。严格，generic repositories是 CRUD 过度泛化，可能会降低代码的表达能力。 “创建”方法也不属于存储库，因为对象生命周期的开始通常由工厂或对象本身处理。当您想要保留现有对象时，“添加”似乎是一个更好的名称，因为存储库具有集合语义。

The question here is how to implement complex queries which involves many aggregate roots. For example, we have two aggregate roots - product and user. If I am doing a page which list what products a user have bought, then I have a query which stretch across both the user aggregate and the product aggregate.

在这种情况下你只需要听业务需求，我强调了我认为最重要的部分。基于此，您似乎需要:

Products products = /* get Products repository implementation */;
IList<Product> res = products.BoughtByUser(User user);

像这样组织代码的想法是尽可能地匹配业务需求和无处不在的语言。存储库接口(interface)的命名也很重要，我更喜欢 产品 或 全部产品 而不是 产品资料库 . Phil Calçado 有一个 very good article关于这个问题，强烈推荐。

How should this query be implemented?

此查询没有什么特别之处，它可以像 Products 存储库中的所有其他查询一样实现。查询本身对域是隐藏的，因为存储库实现属于数据访问层。数据访问可以实现任何查询，因为它对所有聚合及其关系有深入的了解。在这一点上，它只是一个 Hibernate 或 SQL 问题。