コマンドクエリ責任分離

コマンドクエリ責任分離（コマンドクエリせきにんぶんり、英語: Command Query Responsibility Segregation, CQRS）とは、情報技術において、データの更新処理を行うインターフェースと、データの取得処理を行うインターフェースを分離するシステムアーキテクチャである。

概要

CQRSは、コマンドクエリ分離（CQS）の背景にあるアイデアをサービスのレベルにまで拡張させたもので^[1][2]、コマンドクエリ分離と同様に、クエリはデータの状態を取得するだけでログ書き込みなどの例外を除きシステムの状態を変化させず、コマンドはシステムの状態を変化させる。

データを更新する操作とそれに用いられるオブジェクトをコマンドといい、データの取得操作をクエリという。コマンド操作で用いられるデータモデルをコマンドモデル、書き込みモデル^[3]、コマンド実行モデル^[4]などといい、クエリ操作で用いられるデータモデルをクエリモデル、読み取りモデル^[3]、リードモデルなどという^[5][6]。

利用

単純なCRUD処理の場合、データの更新とデータの読み取りに同じデータモデルを用いることが適しているが^[3]、読み取り側と更新側でスループット、遅延、一貫性などに関する要件が異なる場合には、CQRSを用いることが有用である場合がある^[7]。

CQRSにおいては、クエリは、キャッシュや検索インデックスなどを用いることによってデータの読み取りに特化したデータストアを参照することが多くある。また、コマンドの実行がクエリ呼び出しに対して非同期であり、クエリを呼び出した時点で直近のコマンド処理が終了しておらず、データが最新のものに更新されていない（結果整合性）ということは珍しくない。これを解消するために、コマンドを送信したユーザ側でUIの整合性をとるという処理がよく行われるとされる^[8][6][9]。

イベントソーシングはCQRSと共に発表されたアイデアであり^[10]、多くの場合CQRSを用いて実装される^[11]。イベントソーシングはアプリケーションの状態の表現方法の一つであり、状態を永続化するステートソーシングに対して、アプリケーションの状態にどのような変更があったかというイベント履歴を永続化する^[12]。イベントソーシングではイベント履歴からアプリケーションの最新の状態を得るために一定の計算が必要になるが、イベントを登録する際に事前にCQRSにおけるリードモデル側で参照するデータを更新しておくというアプローチを取ることができる。このように、読み取り側が参照する情報をデータの更新時に事前に計算しておくというアプローチのことを、Eager Read Derivationという^[10]。

他のアーキテクチャパターンとの関係

マーティン・ファウラーは以下のように述べている^[13]。

• CRUDを用いてやり取りを行うような単一的な表現から離れることによって、タスクベースなUIへと容易に移行できる。　
• CQRSはイベントベースなプログラミングモデルによく適している。CQRSシステムがイベントコラボレーション（Event Collaboration）により連携する個別のサービスに分割されていることは一般的である。これらのサービスはイベントソーシングの利点を容易に活用できる。
• 分割されたモデルを持つことはモデルの一貫性を保つことがいかに難しいかということについての問題を提起し、最終的に一貫性が保たれる可能性が高まる。
• 多くのドメインにおいては、データを更新する際に多くの業務ロジックを経由する必要があるため、クエリ側のモデルを簡単化するためにEager Read Derivationを用いることが理に適っているかもしれない。
• 書き込みモデルが全ての更新においてイベントを生成する場合、読み込みモデルをイベントポスター（Event Poster）として構造化することにより、これをメモリイメージ（Memory Images）として扱うことができ、データベースと多くのやり取りをすることを回避できる
• CQRSはドメイン駆動設計から恩恵を受けるような複雑なドメインに適している。

関連項目

• コマンドクエリ分離
• ドメイン駆動設計