今日のアプリケーションは一般的に不必要に複雑かCommand Query Responsibility Segregation (CQRS)を使わないことで遅くなっており、ラインオブビジネス (LOB)アプリケーションが複雑な使われ方をするときには、CQRSがもっとも有益なアーキテクチャのひとつであるとGabriel Schenker氏は提示して主張した。
複雑さの理由はアプリケーションが、データのみを持つエンティティとロジックを処理する分離されたサービスを持ち、データの読み込みと変更に同じインターフェイスを使うドメインモデル貧血症が頻繁に含まれていることがひとつの要員であるとSchenker氏は考えている。 Schenker氏によると、分離の欠如により、根本的に異なるものとしてデータを照会することが本当に問題である。読み込みと書き込みを分ける理由には以下が含まれている:
- 書き込むよりもはるかに頻繁にデータを読み込んでいる。
- 1回の集計のみに影響を与える書き込みに対して、データの読み込みは通常、大量のデータか一連のデータである。
- ユーザーの観点から読み込みは、書き込みよりも高速であるべきである。ユーザーはデータが変更された時に応答が遅いことに関しては受け入れる傾向がある。
CQRS Schenkerの基本原則の説明では、商品カタログとショッピングカートを含むショッピングサイトを実装した例で、小さいが実世界に則している。
Vladimir Khorikov氏は、3種類のCQRSと、比較のためのCQRS未使用のものを定義している:
- 同じドメインモデルのNo CQRSは、コマンドとクエリの両方で使われている。これは、コードまたは複雑なオーバーヘッドをなくすが、読み込みを最適化することは、困難または不可能である。
- いくつかの重複を説明するために、読み込んだデータを返すため、コマンドとDTOドメインクラスを使ってクラス構造を分離した。Khorikovは、これがエンタープライズアプリケーションにおいて、複雑さとパフォーマンスのちょうどよいバランスのCQRSのレベルであると考えている。
- 読み込み、書き込みのそれぞれに異なるAPIとモデルの分離されたモデル。最適化されたクエリに加えて、高負荷の読み込みに対しても興味深い、キャッシュも可能である。
- 分離されたストレージは、クエリを最適化して読み込みをさらにスケーリング可能にし、書き込みとクエリのストレージ種類から分離する。たとえば、リレーショナルデータベースやNoSQLなど。読み込みストレージの同期は、一般的に読み込みサイドで結果整合性がバックグラウンドで実行される。最高のスケーラビリティとこのパターンの同居は最高の複雑さをもたらす。
Khorikov氏は、CQRSが択一の選択ではないことを強調する; 分離レベルは、分離度と複雑さの間のバランスを、アプリケーションの必要性から選択するべきであり、読み込みスケーラビリティ要求を満たすためだけに選択するべきである。