CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」を呼んだ結果をまとめ
| 書き込み | 読み込み |
|---|---|
| データの整合性の維持 | データの検索と抽出の効率化 |
| アトミックな更新／トランザクション | 導出値（合計など）の算出 |
| バージョン管理（楽観的並行性制御／楽観的ロック） | 複数のビューの提供 |
| 書き込み権限の管理 | 行レベル、カラムレベルの権限管理 |
CQRSでは、データベースの操作をコマンド（データを書き換える操作）とクエリ（データを読み込む操作）の二つに分類します。
コマンドは一般に、操作の成否以上の情報を呼び出し側に返しません。また、クエリは冪等であることが保証されます。
間にコマンドが挟まらないという前提で、同じクエリを何度実行しても結果は同じになるということです。
RESTでいうと、コマンドはPUTやPOSTに対応し、クエリはGETに対応するものです。
ユーザー情報を更新するというのではなく、「メールアドレスを変更する」「請求先情報を変更する」なとどいうコマンドを考えることができるのです。
呼び出し元が変更しようとしているエンティティのフィールドが本当に変更してよいかどうかをチェックするのではなく、呼び出し元に特定のコマンドを実行する権限があるかどうかだけをチェックすればいいのです。
具体的な実現アーキテクチャとして - 相性がイベントソーシングと良い > 会計処理では、入出金取引（売上や購入など）を元帳にだけ追記していくのががよいとされています。
…現在の口座残高は、必要に応じて過去のすべての取引から算出します。
EventStoreは追記限定の不変なストリームとしてイベントを扱います
あらゆる更新に対応できるような単一のクエリモデルを維持する必要はありません。 「ユーザーの詳細情報の表示」「一日あたりのアクティブユーザー数のレポート出力」など、用途にあわせて最適化したクエリモデルをいくつでも作れるのです。