如何设计事件流，第 3 部分

[导读]他们的主要用例之一是事件溯源。要组合当前状态，您可以将每个更改记录为其自己的事件，然后使用特定的状态组合逻辑按顺序应用这些事件。这是一种事件驱动模式，用于构建内部有数据的系统，因为事件和状态组合逻辑之间存在紧密耦合的关系。

Delta Events 支持事件溯源

但是三角洲事件呢?

他们的主要用例之一是事件溯源。要组合当前状态，您可以将每个更改记录为其自己的事件，然后使用特定的状态组合逻辑按顺序应用这些事件。这是一种事件驱动模式，用于构建内部有数据的系统，因为事件和状态组合逻辑之间存在紧密耦合的关系。

事件溯源：从一系列增量构建状态

每当数据字段更新时都会触发事实事件，而每当满足特定业务逻辑条件时就会触发增量事件。例如，item_added_to_cart只要将商品添加到购物车，就会触发该事件。

一个购物车事实事件与两个与购物车相关的增量事件

Delta 适合捕捉变更背后的意图。它们通常用于向消费者传递通知(例如，食物已准备好取货、收到电子邮件/文本/消息)，这可以提供有用的信号解决方案。

但增量很容易被滥用。一方面，客户倾向于要求细粒度的定制活动来满足下游消费者的需求。例如，“当购物车中添加了 15 件商品时通知我”，或者“当客户在过去 90 天内在鞋子上花费了 1000 美元时通知我”。虽然这些通知对于消费者的业务部门可能至关重要，但它们将确定条件的责任交给了数据生产者——将责任转移到上游，并模糊了哪个系统负责哪个计算。

Delta 不适合在外部重建状态

相反，将特定于消费者的业务逻辑放在下游、关心检测这些条件并根据这些条件采取行动的服务内部。然后，依靠状态事件来确定这些情况何时发生。

复合事件

第三种类型的事件是复合事件：它是事实和增量的组合。

从事实事件开始，您可以添加有关创建该事件的原因的信息。在下面的示例中，我们将“item_added_to_cart”事件创建的原因包括在内(尽管您也可以根据自己的状态自行推断)。

带有“原因”字段的购物车事实，表明其创建原因

同样，您可以选择将其包含在“before/after”事件中，如下所示：

具有之前/之后字段的复合购物车事件

“reason”请注意，向事件添加 a可能会引入与源系统的强耦合。您可能已经注意到：“嘿 Adam，这不就是事实中嵌入的三角洲的名称吗?”你是对的。正是如此。

需要明确的是，我不提倡使用复合事件，因为它们在上游系统的原因填充逻辑上引入了紧密耦合。原因中可能包含很多语义，消费者可能很难理解它们——特别是当添加新语义或删除旧语义时。

这只是构建复合事件的一种方法。您可能还想知道，“但是 Adam，包含某种状态的 delta 事件怎么样?”。虽然从理论上讲，您可以通过这种方式构建复合事件，但现实情况是，大多数增量事件都非常精简，根本不包含任何状态 - 仅包含转换信息。部分原因在于惯例(喜欢使用增量的开发人员通常会尽量减少通过线路发送的所有数据)，部分原因在于边界。我们已经了解了为什么强制消费者根据增量计算状态是有问题的。

现实情况是，复合事件在野外相对较少。我将它们包含在这篇博文中，因为您可能会在自己现有的系统中遇到它们。我从未发现我需要在实践中创建复合事件，而是偏向于外部数据的状态事件，为内部用例的数据留下增量(以及上面提到的原因字段)。

让我们从复合事件开始，回到观察状态。如果您想要传达大量状态，但它不适合事件，您该怎么办?为此，您需要使用索赔支票。

索赔检查模式

声明检查是您在事件中嵌入 URI 的位置，以便消费者可以在需要时访问它以获取更多信息。包含additional_state field一个 URI，您可以在其中获取附加信息，例如文件存储、数据库或 REST 接口。