8 Comments

  1. 我觉得关键是一致性,领域事件本质是引入观察者设计模式进行解耦,如果强行让两个聚合根 分开在两个事务当中,我并没有看到优点,在小型系统中 引入两阶段提交 三阶段提交这些复杂的东西,反倒是让原本简单的东西 变复杂了

  2. Angus

    在保存Order聚合根的时候,如果有OrderCreated事件和多个OrderUpdated事件要发出,如何在事件消费端确保按顺序接受事件,即先收到OrderCreated事件再收到OrderUpdated?

    • 滕云

      这是使用消息机制的常见问题,与具体所使用的消息中间件相关,比如kafka需要保证相关消息落在同一个分区中并且消费组中只有一个consumer,其他的中间件由于架构不同所采用的对顺序消费的保证方式也不同,建议查阅中间件对应的技术文档。

  3. 话说领域事件的发布方式是不是得分两种?一种是通过文中所说的订阅-发布模式,另一种是通过观察者模式?订阅-发布模式与观察者模式还是有些区别的,订阅-发布模式是完全解耦的,通过broker(或是中间件)来调度。。而观察者模式是松耦合且存在一定依赖的,subject知道observer interface的存在。。

    所以我想了解一下,这两种模式是不是都能用在DDD中?最近在做到DDD中的领域事件发布,比较纠结用哪种模式。。好像可以结合一起用。。跨应用的时候订阅发布最适合了吧。。笔者有没有这方面的经验传授一下?

    • 观察者模式的话,【每个】事件发布者需要自己控制事件的消费顺序、丢失事件的重发布,还有事件是同步消费还是异步消费。这往往导致代码拷贝之类的。

      感觉这类动作还是放到infrastructure里比较好,高内聚。

    • 滕云

      根据我的经验,我们很少使用观察者模式,并且这两个东西其实是相对的,举个例子,guava库中eventbus,从使用者的角度,没有耦合,你得到的是发布订阅,但是在eventbus内部实现确是使用的观察者模式。

  4. Edward

    看您写的伪代码示例里,在资源库中发布领域事件是在订单事务保存之前的,如果订单保存失败了,这时候领域事件已经发送出去,会产生一致性的问题。是否应该在应用层得到领域层保存成功的结果后(确保订单持久化成功),再发送领域事件(比如扣除库存、增加积分),这样做有什么问题吗?

    • 滕云

      其实无论如何均不能保证一致性,比如如果订单保存成功,但是事件发送却失败了。如果要保证更新业务对象和发布事件之间的原子性,可以参考一下:https://microservices.io/patterns/data/transactional-outbox.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据