CQRS
概要
コマンドクエリ責務分離
データストアの読み取りと更新を分離する
/icons/point.iconデータモデルを分離すること
データ更新→コマンド
データ読み込み→クエリ
コマンド
データ中心のモデリングではなく、タスクベース
非同期処理のキューに配置する
複雑なビジネス ロジックの多くは書き込みモデルになることが多い
ORM、スキャフォールドなどは使えない
書き込みデータストアと読み取りデータストアとでデータベース自体を分離するようなこともありうる
https://gyazo.com/94f6e290a8a5236f4e98979f96133b1c
イベントソーシングパターンで実装されることもある
従来のアーキテクチャの問題点
データベースの読取と更新とに同じデータモデルが使用される
基本的なCRUDで済むなら問題なし
複雑なアプリケーションだと
モデルの複雑化に繋がる
形式の異なるクエリでDTOマッピングが複雑化
書き込みでは複雑な検証とロジックが実装されていく
読取と書き込みでデータ表現が一致しない場合
読み取りと書き込みでパフォーマンスやスケール要件が異なる(対応できない)
メリット
独立したスケーリング
最適化されたデータ スキーマ
モデルの保守性と柔軟性を向上
クエリがよりシンプルになる
デメリット
アプリケーションの設計が複雑になる
メッセージングでデータ送達保証を考慮する必要
最終的な一貫性
参照
https://learn.microsoft.com/ja-jp/azure/architecture/patterns/cqrs