はじめに
本記事はCQRSについて学んで分かったことをまとめています。
CQRSの概要
日本語ではコマンド/クエリ責務分離と呼ばれるソフトウェアアーキテクチャの1つです。
DDDにおいて広く使われているドメインモデルパターンの問題点を解消するために提案されたアーキテクチャです。
コマンドとクエリ
コマンドはソフトウェアシステムの状態を変更するアクションのことを指します。クエリはソフトウェアシステムの状態を取得するためにデータのみを返すアクションのことを指します。
例として家計簿Webアプリケーションを考えます。アプリケーション上からユーザーの入力によって費用を更新するというアクションは、コマンドに相当します。アプリケーション上に家計簿を表示するために費用を取得するというアクションは、クエリに相当します。
ドメインモデルパターンとCQRSの違い
ドメインモデルパターンとCQRSの大きな違いはドメイン層がコマンドとクエリで分割されているか否かです。
例として、コマンドとクエリでの例と同様に家計簿Webアプリケーションを考えます。
品目名、金額、用途という家計簿の1行分に該当する情報を購入品目という名前の概念で扱っている状況を考えます。
この時、ドメインモデルパターンとCQRSでドメイン層がどのようになるかを考えてみます。
ドメインモデルパターンの場合
ドメインモデルパターンの場合は、コマンドとクエリの両方に対応したモデルを用意して、そのモデルが中心となってドメイン層としての振る舞いを提供します。
つまり、単一の購入品目モデルを利用することになります。
CQRSの場合
CQRSの場合は、コマンドとクエリでドメイン層が分かれます。つまりは、コマンドとクエリ用で別の購入品目モデルを利用することになります。
コマンド用の購入品目モデルは購入品目の状態を変更するためのビジネスロジックを持ちます。対してクエリ用の購入品目モデルは購入品目のデータのみを表現し、ビジネスロジックは持ちません。
CQRSのメリット
ドメインモデルパターンとCQRSを比較した場合のCQRSのメリットは、コマンドとクエリが依存していないことです。CQRSではモデルがコマンドとクエリ用に分かれるので、コマンドとクエリのそれぞれの事情でモデルを容易に拡張できます。対してドメインモデルパターンでは、同じモデルでコマンドとクエリを扱うので、クエリ用にプロパティ1つ追加する場合であってもコマンドへの影響がないかを確認するなど、コマンドとクエリ同士の影響を考えて拡張をしなければなりません。
最後に
本記事ではCQRSについて学んで分かったことをまとめました。まだ深くは理解できていないので、サンプルを自分で作ってみてさらに理解を深めたいと思います。