Microservices DDD中的编舞传奇-集成事件链？

我目前正在研究传奇模式。大多数示例似乎都集中在编排传奇上，其中我们有一个中央传奇执行协调器服务，用于发送和接收消息/事件。不幸的是，关于如何实现编舞传奇的信息似乎有点缺乏

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

假设我们想开始一些传奇故事，例如，我们必须在订单服务和客户服务上运行事务-服务之间究竟是如何通信的？这只是常规的集成事件还是完全不同的事情

在我看来，如下图所示（），这部传奇故事的执行方式如下：

将创建一个新订单。状态设置为“挂起”，并发出OrderSubmittedDomainEvent域事件

域事件处理程序接收OrderSubmittedDomainEvent域事件，然后创建并分派ReserveCreditIntegrationEvent集成事件

客户服务接收ReserveCreditIntegrationEvent集成事件

它试图保留客户信用

如果成功保留信用，则会发出CustomerCreditServedDomainEvent域事件

域事件处理程序收到CustomerCreditServedDomainEvent域事件，它创建并分派CreditReservedIntegrationEvent集成事件

订单服务接收CreditReservedIntegrationEvent集成事件，并将订单状态设置为“已确认”

传奇故事已经完成

这是正确的方法吗

我认为，如果您出于正确的原因选择它，那么对分布式事务使用编排而不是编排是有意义的。例如，如果您需要节省通常更高的精力来实现一个中心编排，那么在事务完成之前，您不需要知道事务处于什么状态。或者是因为您知道事务工作流的顺序是稳定的，不太可能改变，这也是编排的优点。但是，如果顺序经常变化，这将是编排的一个缺点，因为在这种情况下，您需要调整所有的微服务

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

如果你选择编舞的理由是正确的，我会说我在你的考虑中遗漏了补偿逻辑。如果信用卡已被保留，但订单在订单服务中失败，该怎么办？在这种情况下，也需要考虑补偿事件

除此之外，还有一些常见的嫌疑犯：

• 例如，确保每个服务在处理接收到的事件后将可靠地发送下一个事件。为此，您可以查看模式
• 或者确保在每个服务中都实现了事件的重复数据消除。对于跨分布式事务可靠地发送事件，您无法百分之百地确保事件只发送一次

如果您对传奇模式的替代方案感兴趣，您可以研究模式。它非常适合于分布式事务工作流，这些工作流因当前用例的不同而有所不同，因为它避免了每个服务都需要知道每个路由。工作流的顺序附加到事务的初始消息和所有后续消息。然后，接收带有路由条的消息的每个服务执行其任务，并将包含路由条的下一条消息传递给列表上的下一个站点（服务）

注意：我不确定您所说的…IntegrationEvent的确切含义。我不会区分域事件和集成事件，在您的示例中，所有事件都与业务角度相关，否则它们将与其他微服务无关。

我发现此讨论很有帮助：。我不记得它的所有细节，但似乎给出的例子是一个编舞传奇