设计模式 – 如何在DDD中正确设计模型的计算字段？

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

假设我们有两个聚合根：Order和User.订单有两个属性,引用用户：所有者和承包商.业主创建了一个订单,承包商完成了它.

业主可以评估承包商履行订单的质量.所以我们有一个反馈实体,连接到Order,包含评级.

现在,User对象包含每个用户在其完成的订单中的平均评级.而这一部分让我感到困惑.

用户评级不仅仅是一个静态属性,而且实际上是反馈中所有评级的平均值.并且在订单附加反馈时更改(需要重新计算).

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

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

评级似乎是用户的完美属性.但事实上,它不是一个静态的,持久的价值,而是基于其他对象数据计算的东西,让我怀疑.

评级本身也不是一个实体.它既不是价值对象.我想知道,在DDD中它是什么？如何在不牺牲性能和易用性的情况下对系统中的评级(或任何其他可计算的值)进行建模？

公平地说,从另一个AR或另一个BC发出的事件不是泄漏.在我看来,用户AR处理OrderFeedbackGiven事件没有问题.如果反馈VO是事件的一部分,则客户端不需要依赖任何其他事件来处理事件.有一个反馈有限的上下文可能会更清晰,但我不会为此实现一个完整的BC,否则你会爆发微型BC …

I am worried by the fact,that after feedback was given,all
feedbacks must be aggregated to calculate user rating. That creates a
dependency from user to order (calling order repository to fetch
rating from user service,when event was caught). Is this ok,what do
you think?

我认为如果你这样做会没关系.应用程序服务层整体上取决于域层.但是,由于您可以计算moving cumulative average,因此根本不需要这样做.

例如. this.ordersFeedbackAvg是一个MovingAvg值对象,用于跟踪平均值和计算的数据点数.

何时(OrderFeedbackGiven反馈){this.ordersFeedbackAvg = this.ordersFeedbackAvg.cumulate(feedback.mark);}