イベント駆動マイクロサービスを構築する

第3章. 通信とデータ契約

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

コミュニケーションの基本的な問題は、ある点で、別の点で選択されたメッセージを正確または近似的に再現することである。

クロード・シャノン

情報理論の父として知られるシャノンは、プロデューサのメッセージをコンシューマが正確に再現し、内容と意味の両方が正しく伝達されるようにするという、コミュニケーションにおける最大の難関を特定した。プロデューサとコンシューマは、メッセージについて共通の理解を持っていなければならない。そうでなければ、誤解される可能性があり、コミュニケーションは不完全なものとなる。イベント駆動通信では、イベントがメッセージであり、通信の基本単位である。イベントは、何が なぜ起こったのかを、可能な限り正確に記述しなければならない。それは事実の記述であり、システム内の他のすべてのイベントと組み合わされたとき、何が起こったかの完全な履歴を提供する。

イベント駆動型データ契約

通信されるデータの形式と、それが作成されるロジックは、データ契約を形成する。このコントラクトは、イベントデータのプロデューサとコンシューマの両方が従う。それは、イベントが生成されるコンテクストを超えて、イベントに意味と形式を与え、コンシューマ・アプリケーションにデータのユーザビリティを拡張する。

よく定義されたデータ契約には2つの要素がある。1つ目は、データ定義、つまり何がプロデューサになるかである（つまり、フィールド、タイプ、様々なデータ構造）。2つ目のコンポーネントは、トリガー・ロジック、つまり、なぜプロデューサ ーが生成されるのか（つまり、イベント生成をトリガーした特定のビジネス・ロジック）である。 ビジネス要件が進化するにつれて、データ定義とトリガー・ロジックの両方に変更を加えることができる。

データ定義を変更する際には、下流のコンシューマが使用するフィールドを削除したり変更 したりしないように注意しなければならない。同様に、トリガー・ロジックを変更する場合にも注意が必要である。トリガーメカニズムよりもデータ定義を変更する方がはるかに一般的である。

明示的なスキーマを契約として使う

データ・コントラクトを強制し、一貫性を提供する最善の方法は、各イベントのスキーマを定義することである。プロデューサは、データ定義とトリガーロジックを詳述する明示的なスキーマ を定義し、同じタイプのすべてのイベントはこの形式に従う。そうすることで、プロデューサは、コンシューマとなる見込みのあるすべ てのコンシューマに、そのイベント形式を伝達するメカニズムを提供する。コンシューマは、スキーマ化されたデータに対してマイクロサービスのビジネスロジックを自信を持って構築することができる。

警告

明示的な定義済みスキーマを持たないプロデューサとコンシューマ間のイベントベース通信の実装は、必然的に暗黙的なスキーマに依存することになる。暗黙的なデータコントラクトはもろく、制御不能な変更の影響を受けやすいため、下流のコンシューマに不当な苦労を強いることになる。

コンシューマは、ビジネス・プロセスに必要なデータを抽出できなければならないが、どのようなデータが利用可能であるべきかについての期待値を持っていなければ、それを行うことはできない。コンシューマは、データの問題を解決するために、しばしば部族の知識やチーム間のコミュニケーションに頼らなければならない。また、各コンシューマが独自にデータを解釈することを要求することには、大きなリスクがある。コンシューマは、他のコンシューマと異なる解釈をする可能性があり、信頼できる単一の情報源に対する見解に一貫性がなくなるからである。 ...