如何在使用 DDD 的 CQRS 架构中使用 saga？答案

【问题标题】：How to use sagas in a CQRS architecture using DDD?如何在使用 DDD 的 CQRS 架构中使用 saga？
【发布时间】：2017-09-06 09:56:34
【问题描述】：

我正在使用 DDD 设计一个 CQRS 应用程序，并且想知道如何实现以下场景：

一个Participant 聚合可以被多个ParticipantEntry 聚合引用
一个AddParticipantInfoCommand被发送到命令端，其中包含Participant和一个ParticipantEntry的所有信息（类似于Order和一个OrderLineItem）

应该在哪里实现检查 Participant 是否已存在以及如果不存在则创建 Participant 的逻辑？

是否应该在 Saga 中完成，首先检查域模型是否存在 Participant，如果找不到，则发出 AddParticipantCommand，然后发出 AddParticipantEntry 命令，其中包含 @987654331 @?
这是否应该完全由域模型本身中的聚合根来完成？

【问题讨论】：

【解决方案1】：

您不一定需要 sagas 来处理这种情况。请查看我的博客文章，了解为什么不创建聚合根，以及应该怎么做：

【讨论】：

【解决方案2】：

应该在哪里实现检查 Participant 是否已存在以及如果不存在则创建 Participant 的逻辑？

在大多数情况下，此行为应受 Participant 聚合本身的控制。

当您需要跨多个事务边界协调更改时，流程很有用。但是，可以在同一个事务中管理对同一个聚合的两个更改。

您可以将其实现为在同一聚合上运行的两个不同事务，并进行协调；但是过程的额外复杂性并没有带来任何好处。将单个命令发送到聚合并允许它决定要采取哪些操作来维护正确的不变量要简单得多。

Sagas 尤其是一种用于还原多个事务的模式。 Yan Cui 的How the Saga Pattern manages failures with AWS Lambda and Step Functions 很好地说明了旅行预订的传奇。

（注意：关于“saga”的定义存在相当大的混淆；NServiceBus 社区倾向于以与 Garia-Molina and Salem 最初描述的方式略有不同的方式来理解该术语。kellabyte 的 Clarifying the Saga Pattern 调查了这种混淆。）

【讨论】：