上SO（真???）第一個問題，所以大家多多包涵請:)事件採購和傳奇 - 補償事務
我們使用架構採購事件的解決方案。我們的一些業務流程將長期運行，因此我們計劃使用sagas來編排命令至若干聚合根。
在我的理解，如果一個傳奇，發出的命令應該失敗，佐賀縣將負責發行補償命令所有以前調用的總根源。
應該動作的過程中如果聚集體根的狀態將是突變外部（通過某些其它進程/用戶IE）後它需要在佐賀一部分，但之前佐賀失敗並且向該聚合根發出補償命令？
換句話說，如何嘗試補償某個聚合根的事件流（以EventStore術語說話）中不是最後一個的事件？
這是一個相當棘手的情況，因爲我所看到的是，您可能後你的補償項具有無效AR 結束了，讓你的補償行爲無效。
您可能將不得不重新審視流程的設計，以便在確定您的流程管理器（saga）能夠完成之前，不會對AR進行更改。也許暫時存儲值以供稍後更改。
另一種方法可能是阻止AR上的某些命令，如果它處於某種狀態，表明它可能導致這些命令的問題。用戶將無法發佈這些命令。您的流程經理會負責狀態以及任何狀態到期/超時等等。
感謝您的回答。儘管我有一些評論。您首次提出的解決方案看起來很像鎖定，這可能會導致性能問題。第二個提議假設受助組織是他們參與一個傳奇故事的智者，這在我看來是違背了傳奇原則，只有傳奇知道編排細節和ARs才被引用。 – tdaliviu
我不認爲存儲值供以後使用就像鎖定在所有:)第二個選項*可能*只需要獲得傳奇的工作，但如果它是一個麻煩，那麼可能需要另一個解決方案。我以前在流程管理器中使用過相當多的數據，而國家只針對流程管理器。但正如我前面提到的，這是一個棘手的情況。最好的辦法是避開你的現場直播，直到你確信可以安全地應用更改。 –
我一直在給這個想法，我不知道在AR上使用某種'狀態'是否會讓它意識到一個流程管理器。以'訂單'爲例，它的生命週期肯定有一些地位*，但它與業務流程有關。因此不一定與流程管理者有關，但它肯定知道某種形式的業務流程。 –
我想你可以依靠事件中的信息或AR本身來查看補償行爲是否仍然可以發生。如果沒有，那麼您可以啓動需要手動解決衝突的流程。 – plalx