CQRSパターンを実装していないシステムでのCQS原則の完全な価値は何ですか？
コマンドクエリの責任分離を実装していないシステムで、CQS原則の半分の「コマンド」の価値提案を把握するのに問題があります。
CQSの原則では、値を返すメソッドはクエリであり、状態に影響を与えることはありません。状態に影響を与えるメソッドは、決して値を返すべきではありません。
クエリが状態に影響を与えてはならないという原則は、私には完全に理にかなっています。システムに状態を変更するクエリがある場合、コードのロジックについて推論するのは困難です。また、コードが「query」呼び出しによって提供される状態変更に依存していることを忘れた場合、バグが発生しやすくなります。
システムがCQRSとは関係がない場合でも、値を返すメソッドの状態を決して変更しないように努める必要があります。
コマンドから値を返さないという価値命題がわかりません。
コマンド呼び出しの成功に関する情報を含む「結果」を返すようなメソッドを持つことの落とし穴は何ですか？
その原則に従うことで、アプリケーションにどのようなメリットがもたらされますか？
https://martinfowler.com/bliki/CommandQuerySeparation.html のMartin Fowlerによると、コマンドに値を返すことで、ミューテーターとアクセサーの間の境界線を曖昧にします。ただし、原子性が必要な場合を除きます。あなたが得るものは便利さに制限されています。成功/失敗自体は、例外処理を通じて、またはシステムを照会可能な失敗状態に設定することによって伝達されます。いずれにせよ、コマンドは値を返す必要はありません。一方、新しく変更された状態に関する情報を返す場合は、その情報を照会でき、コマンドが値を返す必要はありません。
その利便性を放棄することで得られるものは、どのメソッドが状態を変更し、どのメソッドが変更しないかが一目でわかる明確で具体的な自信です。例としてCのようなものを使用すると、void以外の戻り値の型を持つメソッドは決して状態を変更しないことを確信でき、好きなだけ自由に使用できます-一方、voidの戻り値の型を持つメソッドは状態を変更し、より慎重に使用する必要があります。 Martinも言及しているように、コレクションのPopメソッドなど、より慣用的な意味を持つため、CQSを破ると便利な場合があります。これは明確に定義された操作であり、2つの別々の方法に分割することは完全に可能ですが、単一の操作として保持するよりも有用ではありません。
同様に、前述のように、隣接する操作間で状態が同じであることが保証されておらず、アトミック性が必要なマルチスレッド設定でも注意する必要があります。このような場合、状態をロックして変更し、値を返す必要があります。これはCQSの原則に違反しますが、便利で注意深い方法で行います。