当前位置:  开发笔记 > 编程语言 > 正文

具有副作用的事件采购

如何解决《具有副作用的事件采购》经验,为你挑选了1个好方法。

我正在使用熟悉的事件采购模式构建服务:

    收到请求.

    聚合的历史记录已加载.

    聚合重建(从其历史).

    准备新事件并更新聚合以响应来自步骤1的传入请求.

    这些事件将写入日志,并可供任何订阅者使用(发布).

就我而言,第5步分为两部分.事件将写入事件日志.后台进程从事件日志中读取并发布从偏移量开始的所有事件.

在某些情况下,除了与聚合相关的事件之外,我还需要发布副作用.就系统而言,这些也是事件,因为它们被其他服务消耗并影响其他服务的状态.但是,它们不会影响此服务中聚合的历史记录,也不需要重建它.

我该如何在代码中处理这些?

选项1-不要将副作用事件写入事件日志.在步骤5之前的主要过程中发布这些内容.

选项2-将所有内容写入事件日志,并在加载历史记录时忽略副作用事件.(这些不是历史的一部分!)

选项3-将副作用事件写入虚拟聚合,以便发布它们,但从不加载.

选项4-?

在第一个选项中,如果存在并发冲突,则可能会出现问题.如果在步骤5中写入失败,则副作用不能轻易回滚.第二个选项写入不属于聚合历史记录的事件.在步骤2中加载时,必须忽略这些副作用事件.第三种选择感觉就像一个黑客.

哪一项似乎对你好?



1> theDmi..:

正确命名事件

事件是"发生的事情".因此,如果您能够命名仅以"X发生"方式触发副作用的事件,它们将成为事件历史记录的自然组成部分.

根据我的经验,这总是可行的,因为副作用不是凭空而来的.有时候这个名字变得有点人为,但是以这种方式命名事件比调用它们更好,例如"向该客户端事件发送电子邮件".

就您的备选方案列表而言,这将是备选方案2.

而不是将事件"发送状态电子邮件发送到客户事件",而不是将其称为"状态电子邮件触发事件".当然,如果实际触发器有更好的名称,请使用那个:-)

推荐阅读
保佑欣疼你的芯疼
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有