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

Question

我正在使用DDD設計CQRS應用程序，我想知道如何實現以下場景：

• Participant聚合可以由多個ParticipantEntry聚合引用
• 向Command端發出AddParticipantInfoCommand ，其中包含Participant和一個ParticipantEntry所有信息（類似於Order和一個OrderLineItem ）

應該在哪里實施邏輯來檢查參與者是否已經存在以及是否不存在，創建參與者？

• 是否應該在Saga中首先檢查域模型是否存在Participant ，如果沒有找到，請發出AddParticipantCommand ，然后發出包含Participant ID的AddParticipantEntry命令？
• 這應該完全由域模型本身的聚合器完成嗎？

Answer 1

為了應對這種情況，你不一定需要傳奇。 看看我的博客文章，了解為什么不創建聚合根，以及做什么：

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

Answer 2

應該在哪里實施邏輯來檢查參與者是否已經存在以及是否不存在，創建參與者？

在大多數情況下，此行為應受參與者聚合本身的控制。

當您需要跨多個事務邊界協調更改時，進程非常有用。 但是，可以在同一事務中管理對同一聚合的兩個更改。

您可以將此實現為在同一聚合上運行的兩個不同的事務，並進行協調; 但是過程的額外復雜性並沒有帶來任何好處。 將單個命令發送到聚合更簡單，並允許它決定采取哪些操作來維護正確的不變量。

特別是Sagas是用於恢復多個交易的模式。 Yan Cui的Saga模式如何通過AWS Lambda和Step Functions管理失敗包括旅行預訂傳奇的一個很好的例證。

（注意：關於“saga”的定義存在相當大的混淆; NServiceBus社區傾向於理解這個術語與Garia-Molina和Salem最初描述的方式略有不同.kellabyte的Clarifying the Saga Pattern調查了混亂。）