Domain driven design DDD系统中的查询

这里是DDD noob。假设我们有订单的域聚合（例如）。使用此示例，我们希望查询包含特定项目的所有订单。此外，我们对订单或项目中的所有内容都不感兴趣。只有orderId、日期和项目名称就足以显示回用户/响应API。与以下问题作斗争：

• 存储库（返回域对象）是否返回完整的（即所有属性）匹配订单及其所有项目，然后域对象/服务必须过滤不感兴趣的项目？似乎效率很低，而且没有利用我们的持久性（SQL）引擎功能来缩小搜索范围。此外，此后续筛选将更改域对象的行为（例如，订单的状态及其总数），如果调用者使用此订单的数据/行为，则可能会产生副作用
• 或者存储库返回的DTO类型仅具有调用方所需的数据属性？这似乎很有效，但随着时间的推移，DTO列表可能会增加到数百个类，以满足系统中的某些特定需求。看起来很丑

---

这些担忧是否有效和/或是否有更好的方法？

存储库模式来自Eric Evans的原始领域驱动开发书籍。在第六章中，他讨论了在应用程序逻辑和存储关注点之间进行清晰分离的优势。存储库的概念是，您将拥有一个支持所有域“聚合”对象都可以通过某个内存集合访问的错觉的接口

聚合对象将封装与特定标识符关联的所有状态。理论上，这意味着您将首先从存储库中获取聚合集合，然后枚举这些对象以组成响应，从而回答查询

似乎效率很低，而且没有利用我们的持久性（SQL）引擎功能来缩小搜索范围

是的。一些实现者试验了一个想法，即让存储库接受查询对象作为参数，以尝试解决这个问题

另一种更具吸引力的方法是将更复杂的查询构建到存储库接口中。也就是说，与其尝试创建单一的统一存储库接口，不如创建适合目的的接口——您可以查看存储库契约，并开始了解数据存储需要满足哪些类型的约束

但最重要的一点是——认识到如果您处于读取用例中，实际上并不需要数据模型本身，您只需要创建一些数据的不可变副本。因此，完全跳过该模型，只需使用一个返回不可变DTO表示而不是“聚合根”的存储库

这似乎很有效，但随着时间的推移，DTO列表可能会增加到数百个类，以满足系统中的某些特定需求。看起来很丑

• 它起作用了
• 很简单
• 它反映了支持每个利基需求的实际成本

可能的副本