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

Closed. This question needs to be more focused。它当前不接受答案。












想要改善这个问题吗？更新问题，使它仅关注editing this post的一个问题。

2年前关闭。



Improve this question




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

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

业主可以评价承包商完成Order的质量。因此，我们有一个Feedback实体，连接到Order，其中包含等级。

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

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

让我不满意的是，有关订单聚合根的知识现在已泄漏到UserService中。而且我看不到逃脱它的方法。我开始认为应该有某种模式来处理这种情况。

评分似乎是用户的完美选择。但是，它不是静态的，持久的值，而是基于其他对象数据计算得出的值，这一事实使我感到怀疑。

评级本身也不是一个实体。两者都不是值(value)对象。我想知道DDD是什么？在不牺牲性能和易用性的前提下，如何在系统中对评级(或任何其他可计算的值)进行建模？

最佳答案

公平地说，从另一个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);}

关于design-patterns - 如何在DDD中正确设计模型的计算字段？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/33649885/