architecture-paradigm-cqrs-es

CQRS とイベントソーシングのパラダイム

使用する場合

• 複雑なドメインロジックを持つイベントソーシングシステムを設計する場合
• 状態変更の完全な監査証跡が必要なシステム

使用しない場合

• 複雑なドメインロジックを持たない単純な CRUD アプリケーション
• イベントソーシングによって不要な複雑さが加わる小規模なプロジェクト

このパラダイムを採用する場合

• 読み取りと書き込みのワークロードで、パフォーマンス特性やスケーリング要件に大きな違いがある場合。
• すべてのビジネスイベントを、永続的で不変の履歴または監査証跡に記録する必要がある場合。
• データのプロジェクションを再構築したり、時間軸に沿ったクエリ（例：「昨日、このエンティティの状態はどうなっていましたか？」）に対応したりする必要がある場合。

導入手順

1. 集約を特定する：ドメイン駆動設計の原則に従い、境界づけられたコンテキストと、各コマンドが集約に対して適用すべきビジネス不変条件を明確にします。
2. コマンドとイベントをモデル化する：すべてのコマンドと、それらが生成するイベントのスキーマおよび検証ルールを定義します。バージョニングとスキーマ進化の明確な方針を文書化します。
3. 書き込み側（コマンド側）を実装する：コマンドハンドラーは、集約のイベントストリームを読み込み、ビジネスロジックを実行し、新しいイベントをストリームにアトミックに追加します。
4. 読み取り側のプロジェクションを構築する：イベントストリームのサブスクリプションからデータを受け取る、独立した読み取りモデル（プロジェクション）を作成します。これらのサブスクリプションにバックプレッシャーと再試行のポリシーを実装します。
5. 可観測性を完全に検証する：イベント ID、シーケンス番号、各プロジェクションの遅延時間を追跡するメトリクスを含む詳細なログ記録を実装します。

主な成果物

• 集約、選定したイベントストア技術、プロジェクション戦略、想定するデータ整合性モデル（例：結果整合性の SLA）を詳述したアーキテクチャ決定記録（ADR）。
• インメモリーのイベントストリームを使用するコマンドハンドラーのテスト一式と、それを補完するプロジェクションの統合テスト。
• イベントの再生、パフォーマンス向上のための状態スナップショット取得、スキーマ移行の管理を行う運用ツール。

リスクと軽減策

• 運用負荷の増大：
  • 軽減策：イベントの順序や再生に関するバグは、診断が難しい場合があります。自動化、失敗したイベント用のデッドレターキュー（DLQ）、回復力をテストする定期的な「カオスエンジニアリング」訓練に十分な投資を行います。
• 結果整合性に関する課題：
  • 軽減策：操作を行ってから結果が表示されるまでの遅延に、ユーザーが戸惑う可能性があります。読み取りモデルの更新に関する SLA を明確に文書化し、たとえばコマンド側で即座にフィードバックを提供するなどして、ユーザーの期待を適切に管理します。
• スキーマの乖離：
  • 軽減策：計画されていないイベントスキーマの変更により、コンシューマーが動作しなくなる可能性があります。正式なスキーマレジストリの使用を必須にし、CI/CD パイプラインにバージョンゲートを実装して、検証されていないバージョンのイベントが発行されないようにします。

具体的なコンポーネント

このパラダイムの実装で使用される傾向にあるツールや抽象化の用語です。依存関係ではなく、tools: のフロントマターでもありません。

• event-store：ドメインイベントの追記専用ログ。プロジェクションの構築元となるシステム・オブ・レコード
• message-broker：境界づけられたコンテキスト間でコマンドや統合イベントを運ぶ
• projection-builder：イベントストアを再生して、読み取り側のビューを再構築する

完了基準

• 集約、選定したイベントストア技術、プロジェクション戦略、および各読み取りモデルの結果整合性 SLA を明記した ADR が作成されている。
• コマンドハンドラーのテストがインメモリーのイベントストリームを使用し、永続化アダプターを接続する前に合格している。
• イベントスキーマのスキーマレジストリまたはバージョニング方針が文書化され、その方針に登録されていないバージョンのイベント発行を防ぐ CI ゲートがある。
• 書き込み側を本番環境対応と宣言する前に、イベント再生と状態スナップショットの運用ツールが特定されている（単に言及されているだけではない）。