0

いくつかの質問への回答で、Jonathan Oliver は AsynchronousCommitDispatcher を使用して複数の作業単位を処理することについて言及しています。

私はまだプロジェクトの設計段階にあり (そしてまだ CRQS と ES を学んでいます)、いくつか質問があります。

  1. 発生するドメイン イベントの影響を受ける集約ルートごとに AsynchronousCommitDispatcher を作成しますか?

  2. 別のユーザーによってロックされている場合、ディスパッチされたイベントが集約ルートに変更を加えることができない、ある種のロック メカニズムがある場合はどうなりますか? ロックがある場合、AsynchronousCommitDispatcher は再試行しますか?

  3. ドメイン イベントが処理される前にシステムがダウンした場合はどうなりますか? 未処理であることに固執しなければ、失われてしまうのでしょうか？

  4. 私の最初の理解では、Dispatcher のタイプは、ネットワークを介したメッセージングまたは読み取りモデルの更新用でした。ここでは、別の集約ルートを更新するために使用しています。私はこれが正しいですか？

ティア

JD

4

1 に答える 1

2

コミット ディスパッチャーは、すべてが完全に成功した後に、イベントをネットワークにプッシュすることを目的としています。いいえ、特定のエンドポイントに複数のディスパッチャーは必要ありません。AsyncCommitScheduler (ディスパッチャを使用) はマルチスレッドであり、一度に複数のイベントをディスパッチできます。

ディスパッチャーは、着信メッセージを処理することではありません。それがメッセージ ハンドラーの目的です。ディスパッチャは、すべてが完了すると送信するだけです。

はい、ディスパッチャーは読み取りモデルの更新を支援できますが、あなたが考える方法ではありません。代わりに、ディスパッチャはメッセージをメッセージング フレームワーク (MSMQ、RabbitMQ、またはより高いレベルでは NServiceBus/MassTransit) にプッシュするだけです。次に、ビュー モデルでメッセージを受信したら、それに応じてビュー モデル テーブルを更新します。

于 2012-01-18T02:32:55.733 に答える