Architecture 同步关注点的事件源

我很难理解如何使用支持同步请求的事件源来设计事件驱动的后端。据我所知，要利用事件源，您必须开发对事件作出反应的系统，以便在必要时可以重播事件以重新创建您的状态。为此，这意味着我们正在尝试将事件触发器和事件处理程序解耦

如果我们假设客户机正在发送更新某些数据的请求，那么在使用事件驱动系统时，我们如何适应这种同步请求/响应模型？您是否认为以下步骤是以事件驱动方式处理请求的正确方法：

在API网关接收网络请求，或在网络边缘接收某些服务，并发出表示此请求的事件。此时API网关将挂起并等待

发出的事件由事件存储捕获并记录

具有处理更新的业务逻辑的服务在订阅事件存储时捕获事件。如果能够处理更新，则生成成功事件；如果无法处理更新，则生成错误事件

API网关接收其等待的成功或错误事件之一，并最终将响应发送回浏览器

---

我认为上述内容在很大程度上有助于分离关注点，但我怀疑这是否是通过一个接受外部客户请求的系统来实现事件来源的方法。

您混淆了几个术语和想法，这些术语和想法对保持分离很重要。一旦你在脑海中把它们分开，一切都会变得清晰

事件源和事件驱动架构是两种不同的想法。事件源意味着您将对实体的所有更改保留在事件存储中，并将所有事件相加以获取该实体的当前状态。这个概念与状态的存储有关，而不是请求的处理。我认为您在这个问题中所指的是事件驱动的体系结构。将这些想法分开的必要性很快就会变得清晰

在事件驱动的体系结构中，有两种想法需要分开。有来自UI或外部系统的请求对数据进行一些更改；这是一条消息或请求。消息处理程序（在CQRS中通常称为命令）处理该请求，或者将其视为无效而拒绝，或者对系统中的实体进行适当的更改。然后，对这些实体的更改将作为事件存储在事件存储中。事件存储中的事件应仅包含已更改的数据，而不是实体的所有属性。如果命令更改了多个实体，则会将多个事件写入事件存储

系统可以具有事件存储的侦听器（或订阅服务器），并且可以启动其他业务逻辑以响应实体中的更改。这些更改以最终一致的方式异步运行

考虑到所有这些，我们可以讨论事件驱动体系结构如何处理同步和异步事件。请记住，EDA是为异步处理和最终一致性而设计的，因此使其同步是一项额外的工作

使用上面的4个步骤，我们得到了这个

步骤1：描述的逻辑没有变化。网关接收请求（不是事件）并等待

步骤2：一些开发人员喜欢存储传入的请求以进行模式分析等，但不需要成功地处理请求

在最终一致的体系结构中，业务逻辑将对传入的请求进行一些基本验证，如果看起来不错，则返回操作成功的确认。请求将被放入队列中，并在方便的时候进行处理。如果遇到错误，稍后会通知用户

但由于您的系统是同步的，API（您称之为“API网关”）将直接调用负责处理业务逻辑的服务–命令

步骤3：请求由命令处理，验证请求并对实体进行任何必要的更改。为所有实体更改创建事件（每个实体一个事件）

---

步骤4：该命令同步向API返回成功或失败值，API将其返回给调用方。注意，这应该是一个异步/等待调用，而不是来自API的阻塞调用。对于API和用户来说，这看起来仍然是一个同步过程。

感谢您的回答，并对回复的延迟表示抱歉。你的回答很好，但我对你提出的事件建模有疑问。为什么建议我们为每个要更改的实体创建多个事件？如果我们这样做，我们的“事件”将是CRUD操作，而不是重要的业务事件。在反应式代码库中伪装自己似乎是势在必行的。你对此有答案吗？这些概念中的术语令人困惑，因为它们用同一个词来表示两个截然不同的概念。事件源中的事件只是对实体所做的一组更改，只是CRUD操作。这样做的目的是在以后重新创建该实体，方法是将随着时间的推移所做的所有更改相加，以达到该实体的当前状态。事件源中的事件不反映进行更改的业务原因，只反映更改已进行。事件驱动体系结构中的事件是根据业务规则对某些内容进行更改的请求。本次活动将包含商业理念和目标。EDA中的事件由命令处理，该命令对实体进行必要的更改，从而生成事件源事件。为了将EDA事件与ES事件区分开来，我通常将EDA事件称为“请求”，但不幸的是，我无法决定世界称之为什么。表示域事件然后生成似乎是多余的