domain-driven-design - 在 DDD 系统中查询

Question

DDD菜鸟在这里。假设我们有一个用于 Orders 的域聚合(例如 MS DDD Article )。使用此示例，我们要查询包含特定商品的所有订单。此外，我们对订单或项目中的所有内容并不真正感兴趣。仅 orderId、日期和项目名称就足以显示回用户/响应 API。正在努力解决以下问题:

存储库(返回域对象)是否返回完整(即所有属性)匹配的订单及其所有项目，然后域对象/服务必须过滤不感兴趣的项目？似乎效率很低，并且没有利用我们的持久性 (SQL) 引擎功能来缩小搜索范围。此外，此后续过滤将更改域对象的行为(例如订单的状态及其总数)，如果调用者使用此订单的数据/行为，这可能会导致副作用。

或者存储库是否返回了一个 DTO，它只包含我们需要调用者的数据属性？这看起来很有效，但随着时间的推移，这个 DTO 列表可能会增长到数百个满足系统中某些特定需求的类。看起来很丑

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

Answer 1

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

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

Seems very inefficient and not taking advantage of our persistence (SQL) engine capabilities to narrow a search.

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

另一种获得更多关注的方法是在存储库界面中构建更复杂的查询。也就是说，与其尝试创建单个统一的存储库接口(interface)，不如创建适合用途的接口(interface)——您可以查看存储库契约(Contract)，并开始了解您的数据存储需要满足哪些类型的约束。

但大解锁片是 cqrs -- 意识到如果您处于读取用例中，您实际上并不需要这样的数据模型，您只需要制作一些数据的不可变副本。所以完全跳过模型，只使用一个返回不可变 DTO 表示而不是“聚合根”的存储库。

This seems efficient, except over time this list of DTOs can grow to be hundreds of classes that satisfy some niche requirement in the system. Seems ugly.

有效

很简单

它显示了支持每个利基需求的实际成本。