AgentSkillsCN

cqrs-tradeoffs

协助分析 CQRS（命令查询职责分离）中的一致性、可用性与可扩展性权衡，并作出设计判断。基于 CAP 定理提供 CQRS 的评估维度、与事件溯源结合的影响，以及读写模型分离策略。适用于架构设计、技术选型及现有系统引入 CQRS 的考量。适用语言：与语言无关（Java、Kotlin、Scala、TypeScript、Go、Rust、Python 等均可）。触发条件：“是否应采用 CQRS”、“读写分离的设计”、“结果一致性判断”、“是否应结合事件溯源”、“CQRS 的权衡”、“CQRS 的可用性”、“CQRS 的可扩展性”、“写入模型与读入模型的分离”等与 CQRS 设计判断相关的请求。

SKILL.md
--- frontmatter
name: cqrs-tradeoffs
description: >
  CQRS（Command Query Responsibility Segregation）における一貫性・可用性・スケーラビリティの
  トレードオフ分析と設計判断を支援する。CAP定理に基づくCQRSの評価軸、イベントソーシングとの
  組み合わせによる影響、読み書きモデルの分離戦略を提供する。アーキテクチャ設計、技術選定、
  既存システムのCQRS導入検討時に使用。
  対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。
  トリガー：「CQRSを採用すべきか」「読み書き分離の設計」「結果整合性の判断」
  「イベントソーシングを組み合わせるべきか」「CQRSのトレードオフ」「CQRSの可用性」
  「CQRSのスケーラビリティ」「書き込みモデルと読み込みモデルの分離」
  といったCQRS設計判断関連リクエストで起動。

CQRSトレードオフガイド

CQRSにおける一貫性・可用性・スケーラビリティのトレードオフを分析し、設計判断を支援する。

CAP定理に基づく評価軸

CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。

分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用する。

モデル重視する特性理由
書き込みモデル一貫性現在の状態に基づく意思決定・計算を行うため
読み込みモデル可用性最新の状態でなくても十分な場合が多いため

この分離により、一貫性と可用性を同時に追求するのではなく、各モデルで最適な戦略を選択できる。

CQRSの2つの形態

シンプルなCQRS（イベントソーシングなし）

  • •非CQRSベースのシステムと同様の一貫性を保証
  • •読み書きモデルの論理的な分離
  • •既存のRDBMS上でも実装可能

CQRS + イベントソーシング（CQRS/ES）

  • •読み込みモデルと書き込みモデルで一貫性レベルを独立して制御
  • •書き込みモデル: 強い一貫性
  • •読み込みモデル: 結果整合性
  • •システムの柔軟性が大幅に向上

3つの評価軸

1. 一貫性への影響

書き込みモデル: システムの現在の状態に基づいて意思決定や計算を行うため、強い一貫性が求められる。

読み込みモデル: 最新の状態ではなくても十分な場合が多く、結果整合性が適用される。これにより、パフォーマンスと応答速度の向上が期待できる。

形態書き込みモデルの一貫性読み込みモデルの一貫性
シンプルなCQRS従来と同等従来と同等
CQRS/ES強い一貫性結果整合性

2. 可用性への影響

CQRS/ESでは、書き込みモデルが強い一貫性を必要とする一方、読み込みモデルの結果整合性により高い可用性を実現できる。

障害時の振る舞い:

  • •書き込みを一時停止しても、読み込み操作は継続可能
  • •システムの全面的なダウンを回避できる
  • •キャッシュやレプリケーション機能により、障害発生時でもサービスの可用性を維持

3. スケーラビリティへの影響

読み込みモデルと書き込みモデルを分離して独立にスケールさせることができる。

読み込みモデル:

  • •多くのアプリケーションが読み込み重視
  • •キャッシュやレプリケーションを活用して高いスケーラビリティを実現
  • •異なるマイクロサービスが異なるプロジェクションをホストし、特定のクエリに特化

書き込みモデル:

  • •シャーディングや他の分散技術を活用
  • •書き込み負荷に応じた独立スケーリング

RDB構成との本質的類似性

CQRSのトレードオフは、RDBの1台ライター / N台リードレプリカ構成と本質的に同じである。

観点CQRS/ESRDB 1W/NR構成
書き込み強い一貫性マスターへの書き込み
読み込み結果整合性レプリカからの読み込み
障害時読み込み継続可レプリカで読み込み継続可
スケーリング読み書き独立レプリカ追加で読み込みスケール

どちらもCAP定理に基づくトレードオフが生じるため、同じ考え方が適用される。この類似性を理解することで、CQRSの導入ハードルを下げることができる。

設計判断フロー

CQRSの採用判断

code
1. 読み込みと書き込みの負荷特性が異なるか？
   → No: シンプルなCRUDで十分な可能性
   → Yes: 次へ

2. 読み込みと書き込みで異なるモデルが有利か？
   → No: 単一モデルで対応可能
   → Yes: シンプルなCQRSを検討 → 次へ

3. 読み込みモデルで結果整合性を許容できるか？
   → No: シンプルなCQRS（同一DB）を検討
   → Yes: CQRS/ESを検討 → 次へ

4. 高い可用性・スケーラビリティが要求されるか？
   → No: シンプルなCQRSで十分
   → Yes: CQRS/ES + 読み書きモデルの物理分離を検討

イベントソーシング併用の判断

要件ES不要ES検討
一貫性レベル読み書き同一で可読み書きで独立制御が必要
監査証跡不要必要
時間軸での状態再現不要必要
複雑なプロジェクション1〜2種類多数のビューが必要

結果整合性の許容判断

ドメイン特性結果整合性強い一貫性
SNSフィード表示許容可不要
商品カタログ検索許容可不要
金融取引の残高不可必須
在庫の引当判定不可必須
ダッシュボード集計許容可不要
決済処理不可必須

判断基準: 数秒〜数分の遅延がビジネス上の損害を生むか？

レビューチェックリスト

アーキテクチャ判断

  • • 読み書きの負荷特性を分析したか
  • • CQRSが必要な理由（シンプルなCRUDでは不十分な理由）を明確にしたか
  • • イベントソーシングの要否を判断したか

一貫性設計

  • • 書き込みモデルで強い一貫性が担保されているか
  • • 読み込みモデルの結果整合性がビジネス要件に合致しているか
  • • 結果整合性の遅延許容範囲を定義したか

可用性設計

  • • 書き込み障害時に読み込みが継続できる設計か
  • • 読み込みモデルのキャッシュ・レプリケーション戦略が定義されているか
  • • 障害発生時のフォールバック戦略が明確か

スケーラビリティ設計

  • • 読み込みモデルと書き込みモデルが独立にスケール可能か
  • • 読み込み負荷に対するスケーリング戦略（レプリケーション、キャッシュ等）があるか
  • • 書き込み負荷に対するスケーリング戦略（シャーディング等）があるか
  • • プロジェクション戦略（マイクロサービスごとの特化ビュー等）が定義されているか

関連スキル（併読推奨）

このスキルを使用する際は、以下のスキルも併せて参照すること：

  • •cqrs-to-event-sourcing: CQRSがイベントソーシングを必然的に要求する理由
  • •cqrs-aggregate-modeling: CQRS/ESが集約の境界定義とモデリングに与える影響
  • •aggregate-design: CQRS適用前の集約設計ルール