设计模式 C 如何在DDD中正确设计模型的计算字段?
DDD的忠实粉丝.所以,我正在考虑将它正确应用到我开发的当前系统中.
假设我们有两个聚合根:Order和User.订单有两个属性,引用用户:所有者和承包商.业主创建了一个订单,承
我正在成为 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 我认为如果你这样做会没关系.应用程序服务层整体上取决于域层.但是,由于您可以计算moving cumulative average,因此根本不需要这样做. 例如. this.ordersFeedbackAvg是一个MovingAvg值对象,用于跟踪平均值和计算的数据点数. 何时(OrderFeedbackGiven反馈){this.ordersFeedbackAvg = this.ordersFeedbackAvg.cumulate(feedback.mark);} (编辑:阜阳站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- 依赖注入 C 应该在Java EE7中的限定符中@Nonbinding注释的目
- content pipeline without volume texture support???!!!
- clearmake和gnu make都可以检测出来target之间的循环依赖
- 设计模式 C 如何在DDD中正确设计模型的计算字段?
- activiti学习资料(ProcessEngine引用服务及其依赖关系)
- 由SEDA,HALF-SYNC/HALF-ASYNC 和PIPELINE AND RESOURCE MA
- 依赖注入 – 应该在Java EE7中的限定符中@Nonbinding注释的
- 只有通过实践才能真正了解TDD
- 戴尔聚合网络适配器(Converged Network Adapter, CNA) 在RH
- 用于计算依赖图的部分排序的算法