マイクロサービスアーキテクチャで不良なサードパーティAPIに対処する方法
現在、モノリシックアプリケーションをマイクロサービスベースのアーキテクチャに変換しています。モノリスは、そのデータを（他の部門と同様に）サードパーティのサービスに依存しています。これらのサードパーティサービスのほとんどは、SOAP=を介してアクセスできますが、RESTを使用するものもあります。
これらのサードパーティサービスの一部には、ひどい（使用できないIMOであっても）APIがあります。アグリゲーターサービス（モノリスATM）に不要な複雑さと定型文をたくさん追加します。これらのサードパーティAPIのいずれかのドメインをACLの使用可能なドメインにマッピングして、適切なAPIをアグリゲーターサービスに提供できるようにしているところです。
しかし、不思議に思いました。これは正しい方法ですか？大変な作業ですが、弾丸をかじってこれらの恐ろしいAPIを使用する必要がありますか？サービスの保守性を低下させるマイクロサービスアーキテクチャでひどいサードパーティAPIをどのように処理しますか？
前もって感謝します！
私はいつもこの種の問題に遭遇し、信じられないほどの商用SOAP/XML APIが世の中に出回っています。私が通常行うことは、基本的に2つのことです。
- サービスが実際に必要とする機能のファサードを定義します。これは、私のサービスが消費可能な方法で気にしていることを公開する単純化されたインターフェースです。
- 外部サービスとファサードの間にアダプターを作成します。このアダプターは、ひどいサードパーティのサービスとインターフェースし、すべての詳細を隠します。次に、私のサービスが使用するファサードインターフェイスを実装します。そのため、私のサービスが知っているのは、ファサードの使用方法だけです。
これは私にとっては非常にうまく機能しており、ひどいサービスからより良いサービスに移行した場合でも、サービスはまだファサードを消費するだけなので、何も変更せずに新しいアダプターを実装できるという追加の利点があります。
はい、サードパーティのAPIを呼び出し/非表示にするマイクロサービスが必要です。そのサービスの仕事は、サードパーティのAPIを呼び出す方法を知ることです。面倒なだけでなく、サードパーティサービスの特異性や実装の詳細を設計に取り入れないようにするためです。また、これにより、抽象化または一般化する機会が得られます。その後、APIを切り替えるか、舞台裏で別のテクノロジーに切り替えることもできます。
このようなマイクロサービスは、多くの場合、永続性がなくても実行可能であり、大きな変更はなく、作成後のメンテナンスもそれほど必要ありません。ヘルスチェックエンドポイント、トークン認証など、独自のベストプラクティスを、ドメインが指示するのではなく、そのドメインに導入することができます。