如何在 DDD 中正确设计模型的计算字段？ [关闭]

Question

我正在成为DDD 的忠实粉丝。所以，我正在考虑将其正确应用到我当前开发的系统中。

假设我们有两个聚合根：Order 和 User。 Order 有两个属性，引用User：owner 和contractor。所有者创建了一个Order，承包商完成了它。

业主可以评价承包商履行Order 的质量。所以我们有一个Feedback 实体，连接到Order，包含评级。

现在，User 对象包含每个用户在他履行的订单中的平均评分。这部分让我有点困惑。

User 评分不仅仅是一个静态属性，实际上是Feedbacks 中所有评分的平均值。并且在Order 附加了Feedback 时，它已更改（需要重新计算）。

目前我有一些封装域逻辑的服务：OrderService 和UserService（我知道这实际上不符合 DDD，但我稍后会重构）。当 OrderService 接收到将反馈附加到订单的命令时，它会发出 OrderFeedbackAttachedEvent UserService 监听以重新计算用户评分。

令我不满意的是，关于 Order 聚合根的知识现在泄露到了 UserService 中。而且我看不到逃脱它的方法。我开始认为应该有一些模式来处理这种情况。

评分似乎是用户的完美属性。但它不是一个静态的、持久的值，而是基于其他对象数据计算的某种东西，这一事实让我怀疑。

评级本身也不是一个实体。它也不是一个值对象。我想知道，在 DDD 中它是什么？以及如何在不牺牲性能和易用性的情况下对系统中的评分（或任何其他可计算值）进行建模）？

Answer 1

看来您可能至少有 2 个独立的有界上下文：一个用于排序，另一个用于反馈。

了解有界上下文可以让您看到同一物理事物的不同抽象：在“订单”上下文中，订单似乎是一个合法的聚合，但它可能是“反馈”BC 中的一个值对象，它会持有一个订单 id（该值来自订单 BC 通过事件）。

这是一个建议：

使用此模型，您将在承包商聚合的事件处理程序中从反馈聚合处理“FeedbackEmitted”事件时计算承包商的平均评分

希望这会有所帮助:)

Answer 2

公平地说，从另一个 AR 或另一个 BC 发出的事件不是泄漏。在我看来，User AR 处理OrderFeedbackGiven 事件没有问题。如果Feedback VO 是事件的一部分，那么客户端不需要依赖其他任何东西来处理事件。拥有一个有界反馈的上下文可能会更干净，但我不会为此实现一个完整的 BC，否则你将会有大量的微型 BC...

我担心的是，在给出反馈后，所有 必须汇总反馈以计算用户评分。这创造了一个 从用户到订单的依赖关系（调用订单存储库来获取 用户服务的评级，当事件被捕获时）。这样可以吗，怎么办 你觉得呢？

我认为如果你这样做也没关系。应用服务层作为一个整体依赖于领域层。但是，根本不需要这样做，因为您可以计算 moving cumulative average。

例如其中this.ordersFeedbackAvg 是一个MovingAvg 值对象，用于跟踪平均值以及计算该平均值的数据点数。

when(OrderFeedbackGiven feedback) { this.ordersFeedbackAvg = this.ordersFeedbackAvg.cumulate(feedback.mark); }