イベントソーシングでプロセスマネージャーを実装する方法

私はCQRSとイベントソーシングの概念を学ぶために、小さなサンプルアプリケーションに取り組んでいます。私が持っているBasket骨材とProduct独立して動作するはず集計を。

実装を示すための擬似コードを次に示します

Basket { BasketId; OrderLines; Address; }

// basket events
BasketCreated { BasketId; }
ItemAdded { BasketId; ProductId; Quantity }
AddItemSucceeded { BasketId; ProductId; Quantity }
AddItemRevoked { BasketId; ProductId; Quantity }
ItemRemoved { BasketId; ProductId; Quantity }
CheckedOut { BasketId; Address }

Product { ProductId; Name; Price; }

// product events
ProductReserved { ProductId; Quantity }
ProductReservationFailed { ProductId; Quantity }
ProductReservationCancelled { ProductId; Quantity; }

コマンドはイベントによく似ており、過去形ではなく命令名を使用します。

現在、これらは独立してうまく機能します。コマンドを発行し、集約のイベントをAddItem作成します。このItemAddedイベントBasketは、「バスケット」の状態に対して必要な処理を行います。同様に、製品の場合、コマンドとイベントは正常に機能します。

私はこれを次のようなプロセスに結合したいと思います（発生するコマンドとイベントに関して）：

プロセスマネージャは次のことを行います。

on BasketCreated: CreateShoppingProcess
on ItemAdded: ReserveProduct
on ProductReserved: SucceedAddingItem // does nothing, but needs to be there so that the basket knows it can check out
on ProductReservationFailed: RevokeAddItem
on RemoveItem: CancelProductReservation
on Checkout: CreateOrder // create an order and so on...

決定的な答えを見つけることができなかった質問は次のとおりです。

1. プロセスマネージャーを永続化する必要がありますか？私のように思えますが、よくわかりません
2. その場合、プロセスマネージャーのイベントを保存する必要があります。ただし、リッスンしているイベントは集約に関連付けられています。それらにプロセスIDを追加しますか？プロセスマネージャー専用の個別のイベントはありますか？これを行い、できるだけ乾燥した状態に保つ方法
3. ProductReservedイベントのバスケットを知るにはどうすればよいですか？BasketIdそれらについても大丈夫ですか、それとも情報が漏れていますか？
4. イベント間の関係を維持する方法、どのイベントがどのイベントをItemAdded生成したかをどのようにして知ることができProductReservedますか？に沿って渡しEventIdますか？これは奇妙に思えます...
5. Basket単純な集計ではなく、プロセスマネージャとして実装する必要がありますか？

さらに調査を重ねた結果、「佐賀」は独自のイベントを保持し、外部からのイベントをリッスンするものです。基本的に、それは集合体であり、自身の小さな世界の外で発生するイベントにも反応することができます。

Process Managerは、外部からのイベントを処理し、コマンドを送信します。correlationIdのような共通の識別子を共有するAggregatesで発生したイベントから履歴を再構築できます。

Rinat Abdullinが進化するビジネスプロセスについて書いたことを確認します。特に、急速に変化する環境でビジネスプロセスを開発するための彼の推奨事項に注目してください。プロセスマネージャーは、画面を見つめている人間の「単なる」自動置換です。

私自身のプロセスマネージャーのメンタルモデルは、保留中のコマンドのリストを照会できるイベントソースのプロジェクションです。

プロセスマネージャーを永続化する必要がありますか？私のように思えますが、よくわかりません

これは読み取りモデルです。必要なたびに、イベントの履歴からプロセスマネージャーを再構築できます。または、更新したスナップショットのように扱うことができます。

その場合、プロセスマネージャーのイベントを保存する必要があります。

いいえ-プロセスマネージャはマネージャです。それ自体では何の役に立つこともしません。代わりに、作業を行う（つまり、記録帳に変更を加える）ように集合体に指示します。

ProductReservedイベントのバスケットを知るにはどうすればよいですか？それらにBasketIdを持つことは大丈夫ですか、それとも情報が漏れていますか？

承知しました。 注：ほとんどの「実際の」ショッピングドメインでは、注文を処理する前に在庫を予約することを主張しません。ビジネスに不必要な競合を追加します。あなたのビジネスが注文を受け入れたいと思う可能性が高く、まれに、注文が必要な時間内に履行されないことを謝罪します。

イベント間の関係を維持するにはどうすればよいですか、どのItemAddedがどのProductReservedイベントを生成したかを知るにはどうすればよいですか？

メッセージにはメタデータがあります-特に、causationIdentifier（どのコマンドがどのイベントを生成したかを特定できるようにする）とcorrelationIdentifierを含めると、一般的に会話を追跡できます。

たとえば、プロセスマネージャーは独自のIDをコマンド内のcorrelationIdとして書き込みます。コマンドによって生成されたイベントはコマンドの相関IDをコピーし、プロセスマネージャーは独自のcorrelationIdを持つすべてのイベントをサブスクライブします。

単純な集計ではなく、プロセスマネージャーとしてバスケットを実装する必要がありますか？

私の推薦はいいえです。 しかし、 Udi Dahanはあなたがレビューすべき別の意見を持っています。つまり、CQRSは、集計がサガである場合にのみ意味があります。ウディは、プロセスマネージャが主要なスペルになった場所でサガを使用しました。

プロセスマネージャーは集計を取得する必要がありますか？

あんまり？プロセスマネージャは、ドメインの状態ではなく、主にオーケストレーションに関係します。プロセスのインスタンスには、観察したすべてのイベントの履歴の形式で「状態」があります。イベントZに応答して行う正しいことは、イベントXおよびYを確認したかどうかによって異なります。そのため、その状態の表現（フラットなもの、または観測されたイベントの履歴）を保存およびロードできる必要があります。

ので、（私は「本当にいない」と言うの集計は、それが観察されたイベントのリストがという主張は完全に間違っていないということ漠然と十分に定義されている。我々はロード- 「集約」の違いは実装よりもセマンティックているプロセスの状態を、その後にどのようなメッセージを決めますドメイン状態の原因となるシステムの部分に送信します。ここで少し手を振っています。）

それで、PMは、リプレイ中にライブのことだけを担当するため、あるタイプの状態管理を別のタイプの管理に使用する必要はありませんか？

完全ではありません-状態管理は実行者ではなく、キーパートラッカーです。プロセスマネージャーが信号を発してはならない状況では、世界への不活性な接続を与えます。つまり、dispatch(command)ノーオペレーションです。

あなたが探しているのは、本質的にプロセスマネージャである「Saga」と呼ばれるパターンです。

Sagaは相関コマンド間で状態を維持できるため、長時間実行されるプロセスにも最適です。

Sagasの素晴らしい記事はこちら