DDD菜鸟在这里。假设我们有一个订单的域汇总（例如MS DDD Article）。使用此示例，我们要查询包含特定项目的所有订单。此外，我们对订单或项目中的所有内容都不感兴趣。仅orderId，日期和商品名称就足以显示回用户/响应API。正在努力解决以下问题：
这些关注点是否有效和/或有更好的方法？
答案 0 :(得分：2)
存储库模式来自Eric Evans的原始《域驱动开发》一书。在第六章中，他讨论了将应用程序逻辑与存储问题明确分开的好处。存储库的概念是，您将拥有一个接口，该接口支持以下幻想：可以通过某个位置的内存中集合来访问所有域“聚合”对象。
聚合对象将封装与特定标识符关联的所有状态。从理论上讲，这意味着您将首先从存储库中获取一组聚合，然后枚举这些对象以构成响应，从而回答查询。
似乎效率很低，并且没有利用我们的持久（SQL）引擎功能来缩小搜索范围。
是的。一些实现者尝试了使用存储库来接受查询对象作为参数的想法，以尝试解决此问题。
另一种获得更多关注的方法是在存储库接口中构建更复杂的查询。也就是说，与其尝试创建一个统一的存储库接口，不如创建适合目的的接口，您可以查看存储库合同，并开始了解您的数据存储需要满足哪些约束。 >
但是最大的解锁手段是cqrs －认识到，如果您处于 read 用例中，则实际上并不需要数据模型，您只需要制作一些数据的不可变副本。因此，完全跳过该模型，只使用一个返回不可变DTO表示而不是“聚合根”的存储库即可。
这似乎很有效，只是随着时间的流逝，此DTO列表可以增长为数百个满足系统中某些特定需求的类。看起来很丑。