私はCQRSを見てきましたが、Webアプリケーションなどでコマンドの結果を表示することに関しては制限があることがわかりました。
CQRS を使用すると、ビュー全体またはその一部を更新して (2 番目の要求を使用して) 変更を確認する必要があるように思えます。これは、元のコマンド要求が将来処理されるイベントのみを格納するためです。
Web アプリケーションで、コマンド リクエストが作成したイベントの結果をブラウザに返すことは可能ですか?
私はCQRSを見てきましたが、Webアプリケーションなどでコマンドの結果を表示することに関しては制限があることがわかりました。
CQRS を使用すると、ビュー全体またはその一部を更新して (2 番目の要求を使用して) 変更を確認する必要があるように思えます。これは、元のコマンド要求が将来処理されるイベントのみを格納するためです。
Web アプリケーションで、コマンド リクエストが作成したイベントの結果をブラウザに返すことは可能ですか?
この質問の見出しへの答えは非常に単純です。何もない、無効である、またはウェブブロワー/レストの観点からは、空のボディで200OKです。
システムに適用されたコマンド(変更が正常にコミットされた場合)は結果を生成しません。また、ビジネスロジックをサーバー側に残したい場合は、サーバーに対してさらに別の要求(クエリ)を実行してデータを更新する必要があります。
ただし、ほとんどの場合、サーバーへの2回目のラウンドトリップを取り除くことができます。行を変更するテーブルを取り、保存ボタンを押します。本当にテーブルを更新する必要がありますか?または、ユーザーがブログ投稿にコメントを送信する場合は、ラウンドトリップなしで、DOM内の他のコメントにコメントを追加するだけです。
サーバーから変更された状態を返したい場合は、何を達成しようとしているのかをよく考える必要があります。ほとんどのシナリオは、単純な200OKで十分になるように変更できます。
更新:着信コマンドのキューイングに関する質問について。誤検知が返される可能性があるため、着信コマンドをキューに入れることはお勧めしません(コマンドは正常に受信されてキューに入れられましたが、コマンドがシステムの状態を変更しようとすると失敗します)。ルールには1つの例外があります。それは、状態として追加のみのモデルを持つシステムを使用している場合です。その後、コマンドが有効な場合は、システム状態の変更を後でキューに入れるのが安全です。
ClarifiedCQRSと呼ばれるUdiDahansの記事は、このトピックについて常によく読んでいますhttp://www.udidahan.com/2009/12/09/clarified-cqrs/