event-driven-architecture

イベント駆動アーキテクチャのパターン

イベントソーシング、CQRS、メッセージブローカー、サーガによる調整、結果整合性の管理に関する実証済みのパターンを用いて、イベント駆動システムの設計、実装、運用を支援する専門的なガイダンスです。

このスキルを使用する場面

• 非同期で疎結合な通信を行うシステムを設計する
• イベントソーシングとCQRSのパターンを実装する
• 結果整合性と高いスケーラビリティが求められるシステムを構築する
• マイクロサービス間の分散トランザクションを管理する
• リアルタイムのイベントストリームやデータパイプラインを処理する
• パブリッシュ／サブスクライブ型またはメッセージキュー型のアーキテクチャを実装する
• 複雑なイベントフローを持つリアクティブシステムを設計する

基本原則

1. イベントを第一級の要素として扱う

イベントは、システム内で発生した不変の事実を表します。過去形の名前（OrderCreated、PaymentProcessed）を使用し、必要なコンテキストをすべて含めます。

2. 結果整合性

システムは即時ではなく、時間の経過とともに整合性を実現します。強い整合性と引き換えに、可用性とスケーラビリティを高めます。

3. 疎結合

サービスは直接依存せずにイベントを介して通信し、それぞれが独立して進化、デプロイできるようにします。

4. 非同期通信

処理は応答を待ってブロックしないため、システムの応答性と回復力が向上します。

5. イベント駆動の考え方

何をすべきか（コマンド）ではなく、何が起きたか（イベント）を中心に設計します。

クイックリファレンス

トピック	参照先
イベントの構造、種類、特性	skills/event-driven-architecture/references/event-fundamentals.md
イベントソーシングのパターンと実装	skills/event-driven-architecture/references/event-sourcing.md
読み取り／書き込みを分離するCQRSのパターン	skills/event-driven-architecture/references/cqrs.md
メッセージブローカー（RabbitMQ、Kafka、SQS/SNS）	skills/event-driven-architecture/references/message-brokers.md
分散トランザクションのためのサーガパターン	skills/event-driven-architecture/references/saga-pattern.md
コレオグラフィーとオーケストレーションのパターン	skills/event-driven-architecture/references/choreography-orchestration.md
結果整合性と競合解決	skills/event-driven-architecture/references/eventual-consistency.md
ベストプラクティス、アンチパターン、テスト	skills/event-driven-architecture/references/best-practices.md

ワークフロー

1. 設計フェーズ

• イベントを特定する：どの業務上の事実を記録する必要がありますか？
• 境界を定義する：どのイベントがドメインイベントで、どれが統合イベントですか？
• パターンを選択する：イベントソーシングか、CQRSか、サーガか。コレオグラフィーか、オーケストレーションか。
• テクノロジーを選択する：高スループットにはKafkaか、ルーティングにはRabbitMQか、AWSのマネージドサービスか。

2. 実装フェーズ

• イベントスキーマ：相関IDを含む、バージョン管理されたイベント構造を定義する
• イベントストア：楽観的同時実行制御を用いた追記専用ストレージを実装する
• プロジェクション：クエリを最適化するため、イベントから読み取りモデルを作成する
• ハンドラー：冪等性を確保し、少なくとも1回の配信を処理できるようにする
• サーガ：障害に備えて補償トランザクションを実装する

3. 運用フェーズ

• 監視：イベントの遅延、処理時間、障害率を追跡する
• リプレイ：デバッグや復旧のためにイベントを再生する機能を構築する
• バージョン管理：複数のイベントスキーマバージョンを同時にサポートする
• スケーリング：集約IDでパーティション分割し、コンシューマーを水平方向にスケールする
• テスト：コントラクトテストを用いて、ハンドラーを単独でテストする

よくある間違い

イベント設計の誤り

• ❌ イベントの代わりにコマンドを使用する（CreateOrderではなくOrderCreated）
• ❌ イベントが可変である、またはバージョン管理されていない
• ❌ 相関IDや原因IDのないイベント
• ✓ 不変で過去形の、自己完結したイベントを使用する

整合性に関する問題

• ❌ サービス間で即時に整合性が保たれると想定する
• ❌ イベントの重複配信に対処しない
• ❌ ハンドラーに冪等性がない
• ✓ 結果整合性を前提に設計し、冪等なハンドラーを用意する

アーキテクチャ上の誤り

• ❌ 同期的なイベントチェーン（応答を待つ）
• ❌ 特定のサービス実装に依存するイベント
• ❌ Saga の補償戦略がない
• ✓ 非同期のファイア・アンド・フォーゲット、ドメインに重点を置いたイベント、補償トランザクション

運用上の不足

• ❌ イベントをリプレイする機能がない
• ❌ イベントの遅延を監視できていない
• ❌ スキーマレジストリやバージョン管理がない
• ✓ リプレイに対応し、監視され、スキーマが管理されたイベント

パターン選択ガイド

Event Sourcing を使用する場合：

• すべての変更の完全な監査証跡が必要
• 時系列クエリが必要（「時刻 T における状態」）
• 同じイベントから複数のプロジェクションを作成する
• デバッグや復旧のためにイベントをリプレイする

CQRS を使用する場合：

• 読み取りと書き込みの比率が高い（10:1 以上）
• クエリ要件が複雑
• 読み取りを個別にスケーリングする必要がある
• 読み取りと書き込みで最適なデータベースが異なる

Saga を使用する場合：

• サービス間の分散トランザクションが必要
• 2PC を使わずに原子性を確保する必要がある
• 複雑な複数ステップのワークフローがある
• 補償ロジックが必要

コレオグラフィーを選択する場合：

• シンプルなワークフロー（2～4 ステップ）
• サービスの自律性を高めたい
• イベント駆動型の文化が確立されている
• 複雑な依存関係がない

オーケストレーションを選択する場合：

• 複雑なワークフロー（5 ステップ以上）
• 順次的な依存関係がある
• 一元的な可視性が必要
• ワークフロー内にビジネスロジックがある

リソース

• 書籍：「Designing Event-Driven Systems」（Stopford）、「Versioning in an Event Sourced System」（Young）
• サイト：eventuate.io、event-driven.io、Martin Fowler のイベントソーシングに関する記事
• ツール：Kafka、EventStoreDB、RabbitMQ、Axon Framework、MassTransit
• パターン：Event Sourcing、CQRS、Saga、Outbox、CDC、Event Streaming