CQRS

Command Query Responsibility Segregation

コマンドクエリ責務分離

Write を Command 、 Read を Query として分離するというもの

オブジェクト指向

アーキテクチャへの言及もあり

アーキテクチャ

従来の問題

Read/Writeを同じモデルで行うと、複雑になりすぎる恐れがある

様々な Read の要求に対応するためにマッピングが複雑になるらしい

読み込みと書き込みの負荷が不均衡なときにパフォーマンスチューニングやスケールがしづらい

解決策

https://docs.microsoft.com/ja-jp/azure/architecture/patterns/_images/command-and-query-responsibility-segregation-cqrs-basic.png

読み込みDBと書き込みDBを分離してもいい

データ同期と整合性の維持が少し大変そう

読み込み専用レプリカならよさそう、Amazon Aurora 的な

利点

独立したスケーリング

最適化されたデータスキーマ

セキュリティ

懸念事項の分離

クエリがよりシンプル

実装上の問題

複雑さ

メッセージング

最終的な一貫性

このパターンを使用する状況

多くのユーザが同じデータに並行してアクセスするとき

読み書きのリクエストが不均衡なとき

CQRSパターンとイベントソーシングパターン

ここでは読み込みと書き込みで DB が分離されている前提

イベントを永続化して、 matelialized view として読み込む

実装の複雑度は増す

集計をするイベントが多すぎるときにはデータのスナップショットを実装するといいらしい