DDD中的编排Sagas-集成事件链？

如何解决DDD中的编排Sagas-集成事件链？

我正在研究Saga模式。大多数示例似乎都集中在Orchestration Sagas上，在这里我们有一个中央的传奇执行协调器服务，用于调度和接收消息/事件。不幸的是，似乎缺少有关如何实现编排Sagas的信息。

在域驱动设计中，我们有多个有界上下文，理想情况下，每个有界上下文都是一个自包含的微服务。如果微服务A要与另一个微服务B通信，我们将使用集成事件。集成事件使用某些异步通信（RabbitMQ，Azure服务总线）发布和订阅。

例如，假设我们要启动一些Saga，我们必须在订单服务和客户服务上运行事务-服务之间如何精确通信？是常规的集成事件还是完全不同的事情？

我的观察方式以及下面给出的图片（source），Saga的执行方式如下：

1. 已创建新订单。状态设置为“待处理”，并发出OrderSubmittedDomainEvent域事件。
2. 域事件处理程序接收OrderSubmittedDomainEvent域事件，然后创建并分派ReserveCreditIntegrationEvent集成事件。
3. 客户服务收到ReserveCreditIntegrationEvent集成事件。
4. 它尝试保留客户信用。
5. 如果成功预留信用，则发出CustomerCreditReservedDomainEvent域事件。
6. 域事件处理程序接收到CustomerCreditReservedDomainEvent域事件，它创建并调度CreditReservedIntegrationEvent集成事件。
7. 订单服务收到CreditReservedIntegrationEvent集成事件，并将“订单状态”设置为“已确认”。
8. 传奇完成。

这是正确的方法吗？

解决方法

我认为使用 编排 而不是 Orchestration 进行分布式交易很有意义，如果您选择正确的话原因。例如，如果您 不需要花费通常的精力来完成中央编排，则 不需要知道交易处于什么状态 ，直到交易完成。或者，因为您知道事务工作流程的顺序是稳定的，并且不太可能更改，这在编排方面也是有利的。但是如果编排频繁更改，那么对于编排将是一个缺点，因为在这种情况下，您需要调整 所有微服务 ...

因此，您需要了解这两种方法的优缺点。

如果您出于正确的原因选择了编舞，那么我会认为您在考虑中缺少了 补偿逻辑 。如果保留了信用但订单服务中的订单失败怎么办？在这种情况下，也需要考虑赔偿事件...

除了通常的嫌疑犯之外，

• 例如确保每个服务在处理收到的事件后将可靠地发送下一个事件。为此，您可以查看 Transactional Outbox 模式。
• 或者确保您在每个服务中都实现了重复数据删除，以确保在分布式事务中可靠地发送事件，因此不能百分百确定一个事件仅发送一次。

如果您甚至对Saga模式的替代方法感兴趣，可以查看 Routing Slip 模式。通过避免每个服务都需要知道每个路由，它非常适合根据当前用例而有所不同的分布式事务工作流。工作流的顺序附加到事务的初始消息和所有后续消息。然后，每个接收到带有路由清单的消息的服务都将执行其任务，并将包括路由清单的下一条消息传递到列表中的下一个站点（服务）。

注意：我不确定 ... IntegrationEvent 到底是什么意思。我不会区分 domain 和 integration 事件，在您的示例中，所有事件从业务角度而言都是相关的，否则它们将与其他微服务无关。