CQRSは、状態を変えるCommandと、状態を読むQueryを分けて設計する考え方です。
Read ModelとWrite Model
更新側は、注文確定や在庫引当などのルールを守るモデルを使います。参照側は、一覧や集計画面が読みやすい形を使えます。
Command → Write Model → Store
│
└→ Read Model → Query
同じDBでもCommandとQueryを分けられます。別DBや非同期処理は必須ではありません。
Read Modelの更新
| 方法 | 特徴 |
|---|---|
| 同期 | 更新直後に新しい値を読みやすいが、書き込み処理が増える |
| 非同期 | 更新側を分離しやすいが、反映まで古い表示が残る |
非同期では重複、順序違い、配信失敗を前提にし、更新を再実行可能にします。遅延と失敗件数も監視します。
Event Sourcingは、状態ではなくイベント列を保存する別の考え方です。CQRSと組み合わせることはできますが、CQRSの必須条件ではありません。
向く場合・向かない場合
更新ルールと参照要件が大きく異なる場合に候補になります。
単純なCRUDや常に最新値が必要な機能では、同期処理と監視が増えるだけになり得ます。一部への導入も可能です。
まとめ
- Commandは状態を変更し、Queryは状態を参照する
- 書き込み用と読み取り用で、目的に合うモデルを持てる
- Read Modelは同期でも非同期でもよい
- 非同期更新では遅延、重複、順序、再処理を設計する
- Event Sourcingやマイクロサービスは必須ではない
非同期反映は結果整合性、イベント連携はイベント駆動アーキテクチャで扱います。
参考リソース
← 一覧に戻るPR
PR