なぜサガは読み込み側に問い合わせることができないのですか？

Question

CQRSドメインドリブンデザインシステムでは、サガが読み取り側（http://cqrs.nu）に問い合わせるべきではないとのFAQが記載されています。しかし、サガはコマンドを実行するためにイベントを待ち受け、コマンドを実行するため本質的に「クライアント」なので、なぜサガは読み込みモデルに問い合わせることができないのですか？

Answer 1

Sagasはコマンドモデルを使用してシステムの状態を更新します。コマンドモデルにはビジネスルールが含まれており、特定のドメイン内で変更が有効であることを保証することができます。 これを行うには、コマンドモデルに必要なすべての情報が用意されている必要があります。

読み込みモデルは、まったく異なる目的を持っています。データを構造化して、情報を提供するのに適しています。ウェブページに表示する。

サガにはコマンドモデルから必要な情報がすべて含まれているため、読み込みモデルは必要ありません。 さらに悪いことに、サガからの読み取りモデルを使用すると、追加の結合が導入され、システム全体の複雑さが大幅に増加します。

これは、読んだモデルを絶対に使用できないという意味ではありません。しかし、そうした場合、その結果を理解していることを確認してください。私のために、そのバーはかなり高く、私はいつも別の解決策を見つけました。

Answer 2

サガースは、タスクを実行するために必要な情報について、読者側（予測）に問い合わせるべきではありません。その理由は、読み取り側が最新であることを確認できないためです。最終的な一貫性のあるシステムでは、投影がいつ更新されるのかわからないので、その状態に頼ることはできません。

これは、サガが状態を保持すべきではありません。サガは多くの場合状態を把握する必要がありますが、サガはその状態を作成する責任があります。私が見ているように、これは2つの方法で行うことができます。

イベントストアからイベントを読み取って状態を構築できます。トリガするイベントを受け取ると、ストアから必要なすべてのイベントが読み込まれ、集約と同様の方法で状態が構築されます。これは、新しいストリームを作成してEvent Storeで実行可能にすることができます。

もう1つの方法は、イベントストアからのイベントを継続的に監視し、状態を構築し、予測のようなデータストレージに格納することです。この方法には注意してください。あなたは投影と同じようにサガに返信することはできません。状態の保存方法を変更して再構築する必要がある場合は、すでに実行したコマンドを実行しないようにしてください。

Answer 3

これは主に懸念の分離に関するものです。プロセスマネージャー（sagas）は、活動を調整するステートマシンです。プロセスマネージャが変更に影響を与えたい場合は、コマンドをディスパッチします（非同期）。

また、読み込まれたモデルは何ですか？それはすでに起こった一連のイベントの投影です。だからプロセッサーがそれらのイベントについて気にしていたら...それは彼らに全部加入していないはずですか？ここにモデリングの匂いがあります。

可能性のある問題：このメッセージが到着したときにそれが正しい状態になるように

は、プロセスマネージャは、ストリーム内の以前のメッセージを聞いてきたはずです。

現在のイベントはより豊かでなければなりません（プロセスマネージャが必要とするデータが既に存在するように）。

...変化 - コマンドハンドラは、別のイベントをリスンする必要があり、リッチでなければなりません。

あなたが本当にすでに答え

および他のすべて

の失敗を知って集計するコマンドでなければなりませんしたいクエリは、クエリを実行し、応答でイベントを送出サービスにコマンドを送信します。これは奇妙に聞こえるかもしれませんが、一定の時間が経過したときにプロセスマネージャーがスケジューリングサービスにメッセージを送信して「目を覚ます」ことは既に一般的な習慣です。