CQRS-書き込み側から読み取り側を呼び出すことは許可されていますか？
私はCQRSについて読むことから始めましたが、少し混乱しています。
追加情報を取得するために、書き込み側内で読み取り側を呼び出すことは許可されていますか？
http://cqrs.nu/Faq/command-handlers ここでは許可されていないと言われていますが、cqrsジャーニーコードで、DAOサービスを内部的に使用するサービス「IPricingService」を呼び出していることがわかりました。クラス。
では、集約ルート内で追加情報を取得するにはどうすればよいでしょうか。
CQRSジャーニーはマニュアルと見なされるべきではありません。これは、一部のチームがCQRSへの道を戦い、Microsoftスタックのみを使用するというすべての制限があるという話にすぎません。それ自体、コマンドハンドラーまたはドメインロジックで読み取りモデルを使用しないでください。ただし、クライアントから読み取りモデルを照会して、コマンドに必要なデータをフェッチし、コマンドを検証することができます。
私はこの答えにいくつかの反対意見を得たので、私が書いたのはパターン内で確立された慣行であることを指摘する必要があります。どちらの読み取り側も書き込み側にアクセスせず、書き込み側も読み取り側からデータを取得しません。
ただし、「クライアント」の定義は議論の対象になる可能性があります。たとえば、私は一般向けのJSブラウザアプリケーションが適切な「クライアント」であるとは信じていません。代わりに、REST APIレイヤーをCQRSの「クライアント」として使用し、Webアプリケーションはこのクライアントの単なるUIレイヤーになります。この場合、REST APIサービス呼び出し処理は、偽造を防ぎ、一部のビジネスルールを検証するために、UIレイヤーが送信するすべての内容を検証する必要があるため、正当な読み取り側リーダーになります。この作業が完了すると、コマンドが形成され、に送信されます。書き込み側。検証とその他すべては同期的であり、コマンド処理は非同期的です。
更新：以下のいくつかの不一致に照らして、私は指摘したいと思います 2009年のUdiの記事 CQRS全般、特にコマンドと検証について話します。
CQRS FAQ（ http://cqrs.nu/Faq ）は次のことを示唆しています：
「制限されたコンテキスト間で通信するにはどうすればよいですか？
パブリックAPIに関してのみ。これには、別の制限されたコンテキストからのイベントのサブスクライブが含まれる場合があります。または、ある制限されたコンテキストが別の通常のクライアントのように機能し、コマンドとクエリを送信することもできます。」
したがって、あるBC内では、書き込み側から読み取り側を使用することはできませんが、その逆も可能ですが、別の制限されたコンテキストまたはサービスは使用できます。本質的に、これはユーザーインターフェイスを使用する人間のように動作します。