域驱动设计 – 带副作用的事件采购

概述我正在使用熟悉的事件采购模式构建服务： >收到请求. >加载了聚合的历史记录. >聚合重建(来自其历史). >准备新事件并更新聚合以响应来自步骤1的传入请求. >这些事件将写入日志,并可供任何订阅者使用(发布). 就我而言,第5步分为两部分.事件将写入事件日志.后台进程从事件日志中读取并发布从偏移量开始的所有事件. 在某些情况下,除了与聚合相关的事件之外,我还需要发布副作用.就系统而言,这些也是事 我正在使用熟悉的事件采购模式构建服务：

>收到请求.
>加载了聚合的历史记录.
>聚合重建(来自其历史).
>准备新事件并更新聚合以响应来自步骤1的传入请求.
>这些事件将写入日志,并可供任何订阅者使用(发布).

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

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

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

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

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

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

选项4-
？

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

哪一项似乎对你好？

解决方法 正确命名事件

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

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

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

例

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

总结

以上是内存溢出为你收集整理的域驱动设计 – 带副作用的事件采购全部内容，希望文章能够帮你解决域驱动设计 – 带副作用的事件采购所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。