5

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

  1. 收到请求。
  2. 聚合的历史被加载。
  3. 聚合被重建（从它的历史）。
  4. 准备好新事件并更新聚合以响应来自步骤 1 的传入请求。
  5. 这些事件被写入日志，并可供任何订阅者使用（发布）。

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

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

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

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

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

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

选项 4-？

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

你觉得这些中的哪一个是正确的？

4

3 回答 3

5

正确命名事件

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

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

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

例子

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

于 2016-01-05T06:19:46.153 回答
1

选项 4 - 让其他一些服务订阅事件并产生副作用，以及与它们相关的任何其他事件。

事件应该是细粒度的。

于 2016-01-05T06:08:46.263 回答
0

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

如果您稍后通过构建新的有界上下文需要这部分历史怎么办？

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

如何忽略没有任何影响的东西的影响？:D

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

为什么你需要围绕你永远不会改变的东西的一致性边界？

您所说的是最常见的领域事件形式，您可以使用它与其他 BC-s 进行通信。办公室。你需要保存它们。

于 2016-01-09T03:46:41.737 回答