イベントバスとは? イベントのための共有チャネル
イベントバスは、コンポーネントがイベントを発行し、関心のあるものをサブスクライブする共有チャネルであり、互いを直接参照する必要がありません。
イベントバスは、イベント駆動設計の結合組織です。コンポーネントはイベントをバスに置き、必要なイベントを聞き、誰がそれを生み出したかから疎結合になります。同じ考え方は二つのスケールで現れます。単一のアプリ内のプロセス内イベントバスと、サービス群にまたがる分散イベントバスです。
共有チャネルという考え方
コンポーネントを直接つなぐ代わりに、すべてをバスにつなぎます。パブリッシャーがイベントを投稿し、そのイベント型に登録されたサブスクライバーが呼び出されます。リスナーの追加や削除はパブリッシャーに触れません。
プロセス内対分散
プロセス内イベントバスは、モジュール間でイベントをルーティングする、単一アプリケーション内の単なるオブジェクトです。分散イベントバスはブローカー上で動き、サービス間でイベントをルーティングします。パターンは同じですが、影響範囲と障害モードが異なります。
何に向いているか
- 互いを直接呼び出すべきでないモジュールやサービスを疎結合にする。
- プロデューサーを編集せずに横断的な反応 (監査、通知) を追加する。
- 後でネットワーク越しに分割できる、きれいな継ぎ目を保つ。
- ドメインイベントを、関心のある多数のハンドラーに放送する。
イベントバスのテスト
プロセス内バスはテストが容易です。イベントを発行し、正しいハンドラーが動いたことをアサートするだけで、すべて一つのプロセス内でCIでも高速です。分散バスにはブローカーの存在が必要なので、それらのテストは遅くなり統合レイヤーに置かれます。
隠れた結合に注意
バスは依存関係を隠します。イベント型の変更は、存在を忘れていたサブスクライバーを壊しうるのに、それを捕まえるコンパイラはありません。イベントの形を契約として扱い、パイプラインにそれらに対してサブスクライバーを検証させましょう。
CI環境のどこに位置づくか
分散イベントバスのテストは実行ごとに基盤を起動しますが、プロセス内バスはそうしません。自分がどちらのタイプを持っているかを知ることで、ウォームなrunner (Latchkeyなど) がテスト時間の重い仕事を担っているかどうかが分かります。
重要なポイント
- イベントバスは、イベントを発行・サブスクライブするための共有チャネルです。
- 単一アプリ内のプロセス内と、ブローカー上でサービスをまたぐ分散の両方で存在します。
- その隠れた結合により、イベントスキーマはパイプラインで検証する価値のある契約になります。