CQRS+ESというアーキテクチャがどういったものか気になったので調べたことをまとめてみた。

CQRSとは

コマンドクエリ責務分離(Command Query Responsibility Segregation)の略で、データの読み込み(クエリ)と書き込み(コマンド)の責務を分離するアーキテクチャのこと。

コマンドモデル

コマンドモデルの実行時の最後にはイベントが発行される。

特別なサブスクライバが全てのイベントを受信していて、受け取ったイベントに沿ってクエリモデルを更新し、変更を反映する。

更新を同期的にするか非同期処理にするかはシステムの負荷がどれくらいかかるかによって選択されるべきである。

同期的な場合は一貫性が保たれるが、システム負荷は高くなる。

非同期処理の場合は負荷は抑えられるが、表示されるまでに時間がかかってしまう。

状態(State)を永続化するのではなく、Eventを永続化(ソーシング)すること。

ソフトウェアに何が起きたのか(Event)を記録しておくことで現在の状態を割り出す。

ステートソーシングとは通常のCRUDなアプリケーションでやっているようなもので、

最新の状態だけを永続化すること。

何故、どういう意図を持って状態が変更されたのかというような、状態が変更された経緯が見落とされるという問題がある。

状態遷移は，私たちの問題空間における重要部分であり，私たちのドメインでモデル化されるべきものです。

特定の名前のユーザをすべて検出するというようなクエリが，SQLデータベースで常にテーブルのフルスキャンを行わなければならないような非常に厄介なものになる可能性がある点
書き込みと読み込みを分離して、クエリを最適化することが可能な CQRS の出番

イベントを記録しておくことで在庫数を算出する

例えば4のイベントを取り消したければ3のイベントまで再生することで状態を再現出来る。

イベントを永続化する為のデータストア。

クエリモデルとコマンドモデルをそれぞれ永続化すると、コマンド発行後にクエリモデルが同期されていることを担保することが難しい。

そこでイベントソーシングを組み合わせることで、コマンドモデルでイベントの永続化を行い、永続化されたイベントによって用途に合わせ何度でもいくらでも最適化されたクエリモデルを作ることが可能になる。

実践ドメイン駆動設計