如何在使用DDD的CQRS架构中使用sagas？

Question

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

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

在哪里实施逻辑以检查参与者是否已经存在以及是否不存在，创建参与者？

• 是否应该在首先检查域模型是否存在Participant的Saga中完成，如果找不到它，则发出AddParticipantCommand，然后发出{{1}包含AddParticipantEntry？
的命令
• 这应该完全由域模型本身的聚合器进行吗？

Answer 1

为了应对这种情况，你不一定需要传奇。看看我的博客文章，了解为什么不来创建聚合根，以及做什么：

http://udidahan.com/2009/06/29/dont-create-aggregate-roots/

Answer 2

  

在哪里实施逻辑以检查参与者是否已经存在以及是否不存在，创建参与者？

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

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

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

特别是，Sagas是一种恢复多个交易的模式。严翠的How the Saga Pattern manages failures with AWS Lambda and Step Functions包含旅行预订传奇的一个很好的例证。

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