architecture-paradigm-event-driven

イベント駆動アーキテクチャのパラダイム

使用する場面

• 非同期で疎結合なシステムを構築する場合
• 複雑なイベント処理パイプラインを持つシステム

使用しない場面

• 非同期処理を必要としない、シンプルなリクエスト／レスポンス型アプリケーション
• 強いトランザクション整合性が求められるシステム

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

• 疎結合と非同期処理が有効な、リアルタイムまたは負荷が急増するワークロード（IoT、金融取引、物流など）の場合。
• 複数の独立したサブシステムが、同じビジネスイベントまたはドメインイベントに反応する必要がある場合。
• 既存のサービスを変更せずに新しいコンポーネントを追加できるようにするなど、システムの拡張性を優先する場合。

導入手順

1. イベントをモデル化する：標準イベントスキーマを定義し、明確なバージョニング戦略を確立して、各イベントタイプのオーナーを割り当てます。
2. 適切なトポロジーを選択する：データフローごとに、コレオグラフィ（シンプルなパブ／サブモデルなど）とオーケストレーション（中央コントローラーやサーガオーケストレーターなど）のどちらを採用するか、慎重に選択します。
3. イベントプラットフォームを設計する：適切なイベントブローカーまたはメッセージメッシュを選択します。メッセージの順序、トピックのパーティション、データ保持ポリシーなどの重要なパラメーターを設定します。
4. 障害処理を計画する：デッドレターキュー（DLQ）、自動再試行ロジック、冪等性のあるコンシューマー、イベント再生ツールなど、メッセージ障害を処理する本番環境向けの仕組みを実装します。
5. 可観測性を確保するために計測する：コンシューマーラグ、メッセージスループット、スキーマ検証の失敗、個々のコンシューマーアプリケーションの健全性など、主要なメトリクスを追跡する詳細な監視を実装します。

主な成果物

• イベント分類、選択したブローカーテクノロジー、ガバナンスポリシー（命名、バージョニング、保持など）を記録したアーキテクチャ決定記録（ADR）。
• CI による自動検証とコンシューマー主導のコントラクトテストを備えた、集中管理型のスキーマリポジトリ。
• システム全体のスループット、コンシューマーラグ、DLQ の深さを監視する運用ダッシュボード。

リスクと緩和策

• イベントによる隠れた結合：
  • 緩和策：コンシューマーが、文書化されていないイベントの意味やデータフィールドに暗黙的に依存する可能性があります。正式なイベントカタログまたはスキーマレジストリを公開し、リンティングツールを使ってイベント構造を適用します。
• 運用の複雑さと「ノイズ」：
  • 緩和策：十分な可観測性がなければ、失敗した、または「停止した」コンシューマーの診断は非常に困難です。すべてのイベント駆動コンポーネントで、分散トレーシングと標準化されたアラートを必須にします。
• 「イベントストーミング」による分析麻痺：
  • 緩和策：イベントストーミングのワークショップは有益ですが、適切に運営しないと生産性を失う可能性があります。モデリングセッションには時間制限を設け、まず価値の高いビジネスコンテキストに集中します。

具体的なコンポーネント

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

• message-broker：Kafka、NATS、RabbitMQ。プロデューサーとコンシューマー間の永続的なチャネル
• event-stream-processor：Flink、Faust など。ストリームを消費し、派生イベントを出力します
• distributed-tracing：非同期の各ホップをまたいだ、OpenTelemetry 形式の相関 ID

完了基準

• イベント分類、選択したブローカーテクノロジー、命名規則、バージョニングポリシー、データ保持設定を記録した ADR が作成されている。
• CI 検証により、未登録のイベントスキーマが本番環境に到達するのを阻止する、集中管理型のスキーマリポジトリまたはレジストリが存在する。
• コンシューマーをデプロイする前に、すべてのコンシューマーについてデッドレターキュー（DLQ）の設定と再試行ポリシーが明確に定められている。
• 可観測性ダッシュボードで、少なくともコンシューマーラグ、メッセージスループット、スキーマ検証の失敗率、DLQ の深さを確認できる。