domain-driven-design - 具有副作用的事件溯源

Question

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

1. 收到请求。
2. 已加载聚合的历史记录。
3. 聚合已重建(根据其历史记录)。
4. 已准备好新事件并更新聚合，以响应第 1 步中传入的请求。
5. 这些事件会写入日志，并可供任何订阅者使用(发布)。

就我而言，第 5 步分两部分完成。事件被写入事件日志。后台进程从事件日志中读取并发布从偏移量开始的所有事件。

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

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

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

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

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

选项 4-？

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

您认为以下哪一项是正确的？

Answer 1

正确命名事件

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

根据我的经验，这总是可能的，因为副作用不会凭空发生。有时这个名称会变得有点人为，但以这种方式命名事件仍然比这样调用它们更好。 “向该客户事件发送电子邮件”。

就您的替代方案列表而言，这将是选项 2。

示例

不要将事件称为“向客户发送状态电子邮件事件”，而将其称为“状态电子邮件触发事件”。当然，如果实际触发器有更好的名称，请使用该名称:-)