我正在使用熟悉的事件采购模式构建服务:
收到请求.
聚合的历史记录已加载.
聚合重建(从其历史).
准备新事件并更新聚合以响应来自步骤1的传入请求.
这些事件将写入日志,并可供任何订阅者使用(发布).
就我而言,第5步分为两部分.事件将写入事件日志.后台进程从事件日志中读取并发布从偏移量开始的所有事件.
在某些情况下,除了与聚合相关的事件之外,我还需要发布副作用.就系统而言,这些也是事件,因为它们被其他服务消耗并影响其他服务的状态.但是,它们不会影响此服务中聚合的历史记录,也不需要重建它.
我该如何在代码中处理这些?
选项1-不要将副作用事件写入事件日志.在步骤5之前的主要过程中发布这些内容.
选项2-将所有内容写入事件日志,并在加载历史记录时忽略副作用事件.(这些不是历史的一部分!)
选项3-将副作用事件写入虚拟聚合,以便发布它们,但从不加载.
选项4-?
在第一个选项中,如果存在并发冲突,则可能会出现问题.如果在步骤5中写入失败,则副作用不能轻易回滚.第二个选项写入不属于聚合历史记录的事件.在步骤2中加载时,必须忽略这些副作用事件.第三种选择感觉就像一个黑客.
哪一项似乎对你好?
事件是"发生的事情".因此,如果您能够命名仅以"X发生"方式触发副作用的事件,它们将成为事件历史记录的自然组成部分.
根据我的经验,这总是可行的,因为副作用不是凭空而来的.有时候这个名字变得有点人为,但是以这种方式命名事件比调用它们更好,例如"向该客户端事件发送电子邮件".
就您的备选方案列表而言,这将是备选方案2.
而不是将事件"发送状态电子邮件发送到客户事件",而不是将其称为"状态电子邮件触发事件".当然,如果实际触发器有更好的名称,请使用那个:-)