在 Azure 上实施域事件 (DDD-CQRS)
Implementing Domain Events (DDD-CQRS) on Azure
Microsoft 文档在 "Domain events: design and implementation" 上为 DDD 和 CSRS 提供了 article。
域事件如何在 Azure 上实现。特别是哪些 Azure 服务适合，以及如何组合它们。
到目前为止，关于这个主题的文章相对较少。这个presentation好像不错。它部分讨论了可能的实现；例如Azure Functions 与 Azure 逻辑应用程序；和 Azure 服务总线与 Azure 事件网格。
我怀疑您是在谈论集成事件，而不是领域事件。在您链接到它的文章的第二段中描述了差异，这基本上是在域内创建和使用域事件（通常，但不一定在同一地址 space），而集成事件则绑定不同的域在一起。可以使用诸如 Mediatr 之类的进程内中介服务来管理领域事件。集成事件将被发送到一些外部服务进行交付。
您还应该确保您处理的是事件而不是消息。消息通常是短暂的，携带完整的数据有效负载，并请求执行某些操作。事件有短有长，承载最小负载，并通知相关方某项操作已执行。
您需要做出的另一个决定是您想要事件流还是简单的分发。流会将事件保留很长时间（几天、几周、几个月），而分发会在推送到所有订阅者后丢弃事件。
这里是 a good article 三个可用的 Azure 选项——事件网格、事件中心和服务总线。服务总线用于消息传递，事件中心用于事件流，事件网格用于事件分发。
事件总是领域事件，因为它们是由领域触发的（通常是由聚合触发的）。它们是根据通用语言命名的域对象。它是一个域事件，不管它是被同一个 BC 消费还是被另一个 BC 消费，或者被他们两个消费，都没有关系。
给定一个域事件，如果您想将它从您的 BC 传播出去，以便其他 BC 可以对其做出反应，那么您可以使用中间件消息传递系统机制（Azure 服务总线、RabbitMQ 或其他）。关键是，如果你想让你的 BC 对它触发的域事件做出反应，你不必使用中间件，你可以使用内部机制。但即使在这种情况下，您也应该发布它，因为您的 BC 可能不是唯一对领域事件感兴趣的人。
微软文档中所说的集成事件并不是领域事件之外的另一种事件，它只是中间件使用的消息的数据结构bus/queue，这样当你发布领域事件时，你把它翻译成一条信息。集成事件是一种域事件 DTO。另一方面，消费者 BC 接受集成事件并将其转化为消费者 BC 模型中要完成的操作。
Vaughn Vernon 在红皮书中解释了一种管理域事件的好方法。总结如下：
- BC 内部的静态事件调度程序，触发 BC 上发生的所有域事件。
- 如果您希望同一个 BC 对任何领域事件做出反应，您可以使用静态调度程序为它订阅一个处理程序。
- 您还订阅了一个处理程序，它将所有域事件存储在事件存储中（BC 数据库中的 table）。
- 您还必须实现一个事件转发器，它从事件存储中获取域事件并将它们发布到中间件消息传递系统中。
这是一个 link 似乎很好地实施了我刚刚告诉你的使用 Azure 服务总线的策略：
希望对您有所帮助。
我们决定将我们的系统建立在 Azure Service Bus 的基础上，同时使用其他消息服务（服务网格、事件中心），但用于更窄的任务。
p.s。我们的背景是ERP系统；重点是高价值的业务消息（而不是像其他人那样的速度、吞吐量）。
这个 Mircosofts article 中的论点（由 Azure Service Bus 的架构师）强烈影响了我们的选择。特别是以下内容：
Azure Service Bus
Azure Service Bus is the “Swiss Army Knife” service for all other
generic messaging tasks. While Azure Event Grid and Azure Event Hubs
have a razor-sharp focus on the collection and distribution of events
at great scale, and with great velocity, an Azure Service Bus
namespace is a host for queues holding jobs of critical business
value. It allows for the creation of routes for messages that need to
travel between applications and application modules. It is a solid
platform for workflow and transaction handling and has robust
facilities for dealing with many application fault conditions.
A sale recorded in a point-of-sale solution is both a financial record
and an inventory tracking record, and not a mere event. It’s recorded
in a ledger, which will eventually be merged into a centralized
accounting system, often via several integration bridges, and the
information must not be lost on the way. The sales information,
possibly expressed as separate messages to keep track of the stock
levels at the point of sale, and across the sales region, may be used
to initiate automated resupply orders with order status flowing back
to the point of sale.
A particular strength of Service Bus is also its function as a bridge
between elements of hybrid cloud solutions and systems that include
branch-office or work-site systems. Systems that sit “behind the
firewall”, are roaming across networks, or are occasionally offline
can’t be reached directly via “push” messaging, but require messages
to be sent to an agreed pickup location from where the designated
receiver can obtain them.
Service Bus queues or topic subscriptions are ideal for this use-case,
where the core of the business application lives in the cloud or even
an on-site datacenter, branch-offices, work-sites, or service tenants
spread across the world. This model is particularly popular with SaaS
providers in health care, tax and legal consulting, restaurant
services, and retail.
Composition
Because it’s often difficult to draw sharp lines between the various
use-cases, the three services can also be composed.
e.g. both Service Bus and Event Hub will emit events into Event Grid that will allow applications to react to changes quickly, while not wasting resources on idle time
另一篇好文章（@brad-irby 指出）提供了更多细节和不同的观点：
https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services
我们还添加了 event sourcing 功能；这在我们的上下文中非常重要。
Microsoft 文档在 "Domain events: design and implementation" 上为 DDD 和 CSRS 提供了 article。
域事件如何在 Azure 上实现。特别是哪些 Azure 服务适合，以及如何组合它们。
到目前为止，关于这个主题的文章相对较少。这个presentation好像不错。它部分讨论了可能的实现；例如Azure Functions 与 Azure 逻辑应用程序；和 Azure 服务总线与 Azure 事件网格。
我怀疑您是在谈论集成事件，而不是领域事件。在您链接到它的文章的第二段中描述了差异，这基本上是在域内创建和使用域事件（通常，但不一定在同一地址 space），而集成事件则绑定不同的域在一起。可以使用诸如 Mediatr 之类的进程内中介服务来管理领域事件。集成事件将被发送到一些外部服务进行交付。
您还应该确保您处理的是事件而不是消息。消息通常是短暂的，携带完整的数据有效负载，并请求执行某些操作。事件有短有长，承载最小负载，并通知相关方某项操作已执行。
您需要做出的另一个决定是您想要事件流还是简单的分发。流会将事件保留很长时间（几天、几周、几个月），而分发会在推送到所有订阅者后丢弃事件。
这里是 a good article 三个可用的 Azure 选项——事件网格、事件中心和服务总线。服务总线用于消息传递，事件中心用于事件流，事件网格用于事件分发。
事件总是领域事件，因为它们是由领域触发的（通常是由聚合触发的）。它们是根据通用语言命名的域对象。它是一个域事件，不管它是被同一个 BC 消费还是被另一个 BC 消费，或者被他们两个消费，都没有关系。
给定一个域事件，如果您想将它从您的 BC 传播出去，以便其他 BC 可以对其做出反应，那么您可以使用中间件消息传递系统机制（Azure 服务总线、RabbitMQ 或其他）。关键是，如果你想让你的 BC 对它触发的域事件做出反应，你不必使用中间件，你可以使用内部机制。但即使在这种情况下，您也应该发布它，因为您的 BC 可能不是唯一对领域事件感兴趣的人。
微软文档中所说的集成事件并不是领域事件之外的另一种事件，它只是中间件使用的消息的数据结构bus/queue，这样当你发布领域事件时，你把它翻译成一条信息。集成事件是一种域事件 DTO。另一方面，消费者 BC 接受集成事件并将其转化为消费者 BC 模型中要完成的操作。
Vaughn Vernon 在红皮书中解释了一种管理域事件的好方法。总结如下：
- BC 内部的静态事件调度程序，触发 BC 上发生的所有域事件。
- 如果您希望同一个 BC 对任何领域事件做出反应，您可以使用静态调度程序为它订阅一个处理程序。
- 您还订阅了一个处理程序，它将所有域事件存储在事件存储中（BC 数据库中的 table）。
- 您还必须实现一个事件转发器，它从事件存储中获取域事件并将它们发布到中间件消息传递系统中。
这是一个 link 似乎很好地实施了我刚刚告诉你的使用 Azure 服务总线的策略：
希望对您有所帮助。
我们决定将我们的系统建立在 Azure Service Bus 的基础上，同时使用其他消息服务（服务网格、事件中心），但用于更窄的任务。
p.s。我们的背景是ERP系统；重点是高价值的业务消息（而不是像其他人那样的速度、吞吐量）。
这个 Mircosofts article 中的论点（由 Azure Service Bus 的架构师）强烈影响了我们的选择。特别是以下内容：
Azure Service Bus
Azure Service Bus is the “Swiss Army Knife” service for all other generic messaging tasks. While Azure Event Grid and Azure Event Hubs have a razor-sharp focus on the collection and distribution of events at great scale, and with great velocity, an Azure Service Bus namespace is a host for queues holding jobs of critical business value. It allows for the creation of routes for messages that need to travel between applications and application modules. It is a solid platform for workflow and transaction handling and has robust facilities for dealing with many application fault conditions.
A sale recorded in a point-of-sale solution is both a financial record and an inventory tracking record, and not a mere event. It’s recorded in a ledger, which will eventually be merged into a centralized accounting system, often via several integration bridges, and the information must not be lost on the way. The sales information, possibly expressed as separate messages to keep track of the stock levels at the point of sale, and across the sales region, may be used to initiate automated resupply orders with order status flowing back to the point of sale.
A particular strength of Service Bus is also its function as a bridge between elements of hybrid cloud solutions and systems that include branch-office or work-site systems. Systems that sit “behind the firewall”, are roaming across networks, or are occasionally offline can’t be reached directly via “push” messaging, but require messages to be sent to an agreed pickup location from where the designated receiver can obtain them.
Service Bus queues or topic subscriptions are ideal for this use-case, where the core of the business application lives in the cloud or even an on-site datacenter, branch-offices, work-sites, or service tenants spread across the world. This model is particularly popular with SaaS providers in health care, tax and legal consulting, restaurant services, and retail.
Composition
Because it’s often difficult to draw sharp lines between the various use-cases, the three services can also be composed.
e.g. both Service Bus and Event Hub will emit events into Event Grid that will allow applications to react to changes quickly, while not wasting resources on idle time
另一篇好文章（@brad-irby 指出）提供了更多细节和不同的观点： https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services
我们还添加了 event sourcing 功能；这在我们的上下文中非常重要。