イベント駆動型ソフトウェアアーキテクチャ

イベント

ビジネスプロセスで意味のある状態の変化。たとえば、購入注文の実行は意味のあるイベントです。注文履行センターで、注文を処理する前に通知を受け取ることが必要であるためです。

イベントメッセージ

イベントに関するデータが含まれるメッセージ。イベント通知とも呼ばれます。たとえば、注文についての情報を含む発注関連の通知をイベントメッセージにすることができます。

イベントプロデューサー

イベントメッセージのパブリッシャー。

イベントチャネル

イベントのストリームで、そのストリーム上でイベントプロデューサーはイベントメッセージを送信し、イベントコンシューマーはそのメッセージを読み込みます。プラットフォームイベントの場合、このチャネルは、単一プラットフォームイベント用のチャネルであるか、または複数のプラットフォームイベントのイベントメッセージをグループ化するカスタムチャネルです。

イベントコンシューマー

チャネルからのメッセージを受信するチャネルのサブスクライバー。たとえば、新規注文についての通知を受け取る注文履行アプリケーションなどがあります。

イベントバス

公開/登録モデルに基づくマルチテナント、マルチクラウドのイベントストレージおよび配信サービス。イベントバスにより、保持期間内であればいつでも、保存されているイベントメッセージを取得できます。イベントバスは、時間順のイベントログに基づいています。これにより、イベントメッセージは、Salesforce で受信された順序で保存および配信されます。

要求-応答通信モデルでは、システムは Web サービスまたはデータベースに対して要求を実行し、特定の状態に関する情報を取得します。要求の送信者はサービスへの接続を確立し、サービスの可用性に依存しますん。

これと比較して、イベントベースモデルでは、システムはイベントの発生時に情報を取得し、その情報にほぼリアルタイムで対応できます。イベントプロデューサーは、イベントを受信するコンシューマーを認識しません。任意の数のコンシューマーが同じイベントを受信してそのイベントに対応できます。プロデューサーとコンシューマー間の唯一の連動関係は、メッセージコンテンツのセマンティックです。

イベントバス

プラットフォームイベントメッセージはイベントバスに公開され、そこで一時的に保存されます。Streaming API (CometD) または Pub/Sub API クライアントを使用して、保存されたイベントメッセージをイベントバスから取得できます。各イベントメッセージに、ストリーム内のイベントを識別する ReplayId 項目が含まれており、これを使用して特定のイベント後のストリームを再生できます。詳細は、『ストリーミング API 開発者ガイド』の「メッセージの永続性」を参照してください。