design-patterns - 如何在 DDD 中正确设计模型的计算字段？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。




Improve this question




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

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

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

现在，User对象包含每个用户完成的订单的平均评分。这部分让我有点困惑。
User rating 不仅是一个静态属性，而且实际上是 Feedbacks 中所有评分的平均值。 .并且它现在改变了(需要重新计算)Order有 Feedback随附的。

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

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

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

评级本身也不是一个实体。它既不是值对象。我想知道，在 DDD 中它是什么？以及如何在我的系统中为评级(或任何其他可计算值)建模而不牺​​牲性能和易用性)？

Answer 1

看起来您可能至少有 2 个分离的有界上下文:一个用于订购，另一个用于反馈。

认识有界上下文允许您查看同一物理事物的不同抽象:在“订单”上下文中，订单似乎是一个合法的聚合，但它可能是“反馈”BC 中的值对象，在那里它将持有订单id(该值来自订单 BC 通过事件)。

这是一个建议:




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

希望这可以帮助 :)