什么时候将事件推送到 ES 中的事件存储？答案

【问题标题】：When is an event pushed to the event store in ES?什么时候将事件推送到 ES 中的事件存储？
【发布时间】：2021-04-21 15:39:24
【问题描述】：

我正在尝试一些新概念，包括事件溯源、微服务以及所有这些范式。

假设我们有以下结构，它代表了一个基本的事件驱动架构

UI -> API -> EVENTS BROKER ->> MICROSERVICES

我们从客户端 (UI) 向服务器 (API) 发出请求，执行的命令会引发一个事件，该事件会发布到 >EVENTS BROKER 然后订阅该特定事件的每个服务都将启动一个过程，对吗？但是如果我还想实现事件溯源怎么办，看起来可能是这样吗？

UI -> API -> EVENTS BROKER ->> MICROSERVICES
          -> EVENTS STORE

对于这个例子，假设我有一个名为 Products 的聚合，如果在我将事件保存在事件存储中之后，我的业务逻辑说它不应该被允许，因为我现在不应该，也许我们只在该月的特定日期接受新产品，但现在我已经存储了该事件

问题本身是，在这种情况下，我应该什么时候将事件保存到 EVENT STORE 中？

【问题讨论】：

【解决方案1】：

在事件溯源中，基本方法是只保存有效事件。因此，在处理命令以确定需要发出和保存哪些事件时，取决于您的 API。 API 服务应该是唯一决定将哪些事件写入事件存储的东西（并且通常通过查询事件存储的进程将事件发布到事件代理是一个好主意：任何事件都不应该发布到未由 API 服务写入事件存储的代理）。

现在，如果后来决定不应创建 20 日星期二创建的产品，则无法删除该事件：产品已创建是事实。但是您可以创建一个新事件，可能称为ProductCreationRetracted，解释为：“糟糕，这个产品不应该被创造出来”。

一般而言，这将需要修改任何为Products 读取或写入事件的内容（除非，例如，通过某种标记，您可以确定它永远不会看到ProductCreationRetracted 事件。

还值得注意的是，在事件源 DDD 中，确保只有一个进程正在为给定聚合根写入事件通常很重要（取决于用于从事件派生状态的特定代数，此要求可能能够放宽：例如，如果代数定义了无冲突的复制数据类型（并且如果您不知道 CRDT 是什么，那么默认假设您不能放宽单个写入器可能是合理的）。

【讨论】：

【解决方案2】：

如果我也想实现事件溯源怎么办，它可能看起来是这样吗？

UI -> API -> EVENTS BROKER ->> MICROSERVICES
          -> EVENTS STORE

通常不？它更有可能看起来像这样：

UI -> API -> EVENTS STORE ->> EVENTS BROKER ->> MICROSERVICES

也就是说，我们通常会在发布数据模型之前将更改持久化，并且当我们切换到事件溯源时，该顺序不会改变。

毕竟，事件溯源“只是”使用仅附加的事件序列作为我们的数据模型，而不是文档存储中的文档或关系数据库中的行。因此，保存发生在同一个地方是正常的（“事务边界”与数据模型无关）。

【讨论】：

【解决方案3】：

要记住的重要一点是，您需要将事件溯源与事件驱动架构分开。这些不一样。

来自 UI 的命令被发送到特定服务，该服务可以在内部使用 CQRS/事件溯源来保存自己的记录（实施细节）。然后它可以选择将事件发布到其他服务。 UI 不向系统发送事件，只向系统发送命令。

您在有限的上下文中使用事件溯源，并且您在服务之间使用不同的事件（以避免耦合）。就像这张照片所示：

内部的事件与外部的事件不同（服务之间）。

【讨论】：