事件驱动架构中的领域事件 vs 事件通知 vs 事件携带的状态传输 ECST，实现领域驱动设计 (DDD)

Question

我想澄清一下在实现 DDD（领域驱动设计）的 EDA 系统（具有事件驱动架构的系统）中实现不同类型事件的方式。假设我们没有使用事件源。

更具体地说，阅读相关文章后，似乎有 3 种事件：

• 事件通知：这种事件看似没有太多细节，只是通知已经发生的事件，提供查询更多信息的方式。

"type": "paycheck-generated",
"event-id": "537ec7c2-d1a1-2005-8654-96aee1116b72", 
"delivery-id": "05011927-a328-4860-a106-737b2929db4e", 
"timestamp": 1615726445,
"payload": {
"employee-id": "456123",
"link": "/paychecks/456123/2021/01" }
}

• 事件携带状态转移（ECST）：此事件似乎有两种类型，要么具有某些已更改信息的增量，要么包含资源的所有相关信息（快照）。

{
"type": "customer-updated",
"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", 
"customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", 
"timestamp": 1615728520,
"payload": {
"first-name": "Carolyn", 
"last-name": "Hayes",
"phone": "555-1022",
"status": "follow-up-set", 
"follow-up-date": "2021/05/08", 
"birthday": "1982/04/05", 
"version": 7
 } 
}

{
"type": "customer-updated",
"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", 
"customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", 
"timestamp": 1615728520,
"payload": {
"status": "follow-up-set", 
"follow-up-date": "2021/05/10", 
"version": 8
} 
}

• 域事件：此事件位于其他两个事件之间，它比事件通知具有更多信息，但此信息与特定域更相关。

上面的每个示例均来自 Khononov 的书（学习领域驱动设计：调整软件架构和业务策略）

说了前面的陈述，我想澄清以下问题：

(1) 与其他有界上下文通信时，事件携带状态转移 (ECST) 和事件通知类型的典型用途是否以集成事件（在 DDD EDA 系统中）的形式使用？ （通过将领域事件转换为集成 事件取决于用例）

(2) 使用事件驱动架构的领域驱动设计系统中是否存在一种或多种其他典型事件类别？例如：发生域错误时的事件通知 - 针对特定错误的客户端通知（在这种情况下，没有发生聚合持久性） - 这些类型的错误如何传播回客户端，以及名称可能是什么DDD EDA 社区接受的此类活动有哪些？

Answer 1

我想说有两种不同类型的事件：领域事件和应用程序（或集成）事件。

领域事件实际上是领域中的变化。如果我们有一个“人员”聚合，那么某些域事件可能是“人员名字已更改”、“人员姓氏已更改”、“人员电子邮件已更改”。现在，事件的接口由您决定，您可以发出聚合的 ID 并让客户端通过 API 或类似的方式检索更新的值，或者您可以发出已更改的内容（例如，如果“人的名字已更改” " 被发出，然后发送新的名字）。

应用程序事件是由于应用程序级别发生某些事情而发出的事件。想象一下我们有一个 UpdatePersonDetails 用例。在此用例中，可能会对人员进行大量修改：名字、姓氏、电子邮件。除了发出领域事件之外，您可能还希望在该用例作为一个整体执行时发出一个事件，因为这对您的业务可能很重要。

对于您的问题 2：如果聚合没有变化，那么它肯定不是领域事件（除非故障具有业务概念），而是应用程序事件。在这种情况下，您可以发出类似“更新人员用例失败”事件的信息。