CQS によって、コマンドが状況変数を返すのを防ぐ場合、成功しない可能性のあるコマンドをどのようにコーディングしますか? 例外に頼ることができないとしましょう。
リクエスト/レスポンスはすべてCQSに違反しているようです。
そのため、コマンドによって返されるステータスを示す「mother may I」メソッドのセットがあるように見えます。マルチスレッド/マルチコンピュータ アプリケーションでは何が起こるでしょうか?
サーバーのオブジェクトを 1 つ増やすように要求しようとしているクライアントが 3 つある場合 (オブジェクトには 0 ～ 100 の制限があります)。すべてができるかどうかを確認しますが、1 つが取得できます。他の 2 つは制限に達したため取得できません。ここでは、返されたステータスが問題を解決するように思えます。
リクエスト/レスポンスはすべてCQSに違反しているようです。
ほとんどそうです。したがって、 Command-Query- Separationです。マーティン・ファウラーがうまく表現しているように：
基本的な考え方は、オブジェクトのメソッドを 2 つの明確に分離されたカテゴリに分割する必要があるということです。
クエリ: 結果を返し、システムの監視可能な状態を変更しません (副作用はありません)。
コマンド: システムの状態を変更しますが、値を返しません[強調]。
サーバーのオブジェクトを 1 つ増やすように要求するのはCommandであるため、値を返すべきではありません。その要求に対する応答を処理するということは、CQS の基本原則を破るコマンドとクエリ アクションを同時に実行していることを意味します。
したがって、サーバーの値を知りたい場合は、別のQueryを発行します。
リクエストとレスポンスのパターンが本当に必要な場合は、複雑なコールバック イベント プロセスのようなものが必要で、特定のリクエストのステータスのクエリを発行するか、システムのこの部分に純粋なCQS が適していないかのどちらかです。純粋な。
マルチスレッド化は CQS の主な欠点であり、実行が困難になる可能性があります。ウィキペディアには、これに関する基本的な例と議論があり、同じ Martin Fowler の記事へのリンクもあります。彼は、自分を狂わせることなく何かを成し遂げるために、パターンを破っても問題ないと示唆しています。
[Bertrand] Meyer [CQS の発明者] はコマンドとクエリの分離を絶対的に好んで使用しますが、例外もあります。スタックのポップは、状態を変更するクエリの良い例です。Meyer は、この方法を避けることができると正しく言っていますが、これは便利なイディオムです。ですから、できる限りこの原則に従うことを好みますが、ポップを得るためにそれを破る準備ができています.
TL;DR - 正しい CQS でなくても、おそらく応答を返すことだけを検討します。
記事「Race Conditions Don't Exist」は、CQS/CQRS の考え方の問題を調べるのに役立つ場合があります。
一歩下がって、コマンドを送信する前にカウンター値を知る必要がある理由を尋ねてみてください。どうやら、カウンターをさらに増やすことができるかどうかをクライアント側で決定したいようです。
アプローチは、サーバーにそのような決定をさせることです。すべてのクライアントがコマンドを送信できるようにします (一部は成功し、一部は失敗します)。最終的に、クライアントはサーバー オブジェクトの状態 (制限に達した場所) の一貫したビューを取得し、最終的にそのようなコマンドの送信を停止する可能性があります。
この時間枠の不一致は、クライアントによる誤った決定につながりますが、コマンドが適切に処理される限り、サーバー側のオブジェクト (またはドメイン モデル) の一貫性が損なわれることはありません。