フィールド名が頻繁に更新されるデータモデルのAPI設計
フィールド名を頻繁に更新する外部データモデルフレームワークがあります。私が実装するイテレーションについて言う
- EnterpriseModelObject
-- EnterpriseDomainContentList
--- EnterpriseDomainContent
-- ContentDeliveryResult
--- ErrorList
---- Error
--- WarningList
---- Warning
これは次の反復になります
- EnterpriseModelObject
-- EnterpriseContentList
--- EnterpriseContent
-- DeliveryResult
--- EnterpriseErrorList
---- EnterpriseError
--- EnterpriseWarningList
---- EnterpriseWarning
さまざまなBeanタイプをこのモデルに変換したり戻したりする必要があるマイクロサービスがいくつかあります。このために私は一般的な作業を行うライブラリーを持っていますが、私のBeanモデルが変更されたときの更新にはまだ苦労しています。
マイクロサービスは、モデル内のオブジェクト名を直接使用するように実装されており、ライブラリは一般的な変換方法を提供するだけです。そのため、変換ライブラリの更新を開始すると、サービスAPIの単体テストが失敗します。理想的には、ライブラリへのすべてのオブジェクト名の変更をローカライズできるようにしたいのですが、サービスは、マイクロマネージメントを必要とせずに正しいフィールドを返します。
コンパイルや単体テストの問題なしに更新が自動的に使用されるようにするには、サービスでどのようなアプローチを取るべきですか？
あなたは間違いなくあなたのためにあなたの仕事を切り取ってもらいました。変更の速度と、常に新しいAPIバージョンに移行する必要がある要件のため、オプションのセットは限られています。
オプション1
この面倒なAPIをラップするマイクロサービスを作成します。唯一の目的は、アプリケーションに一貫したインターフェースを提供することです。マイクロサービスは、外部APIの1つのバージョンにマッピングされてデプロイされ、新しいバージョンが出てきたら、それを適応させて再デプロイします。
現在マイクロサービスアーキテクチャを使用していない場合でも、最新の状態を維持し、デプロイされたアプリケーションでそれを有用にする方法があります。利点は次のとおりです。
- マイクロサービスのデプロイメントスケジュールがアプリケーションのデプロイメントに関連付けられていない
- 一貫性のあるAPIはチャーンをスムーズにし、既知のデータモデルでの作業を可能にします
もちろん、これはラッピングするAPIがWebベースの場合にのみ簡単です。注意事項は次のとおりです。
- API呼び出しが書き換えられて転送されるため、レイテンシが増加する
- 問題のサブセットに限定
オプション2
マイクロサービスソリューションと同じことを行うコンポーネントをアプリケーション内に作成しますが、これはコードの一部です。準備ができたら、サービスの新しいバージョンをデプロイできます。呼び出すバージョンに応じて、サービスの正しい実装を選択することもできます。
利点：
- コンポーネントがコードに埋め込まれているため、追加のレイテンシはありません
- 呼び出すAPIのタイプに限定されない
- 一貫性のあるインターフェースにより、面倒なAPIの使用がスムーズになります
警告：
- アプリケーションのデプロイに関連付けられた新しいラッパーのデプロイ
残りのオプションは、上記のオプションの異なるフレーバーです
オブジェクトマッピングコードを抽象化する場合でも、API全体を抽象化する場合でも、重要なのは、ソリューションで次のことを確認する必要があることです。
- 壊れた適応を修正するコードは中央に配置されています
- 外部APIオブジェクトの変更は、コード全体に波及効果をもたらしません
- 可能であれば、より安定した寿命を持つ一連の既知のクラスに変更を適応させる手段があります。
私はあなたの幸運を祈ります。それは醜い問題であり、かなりの解決策はありません。一般的な考え方は、抽象化の適切なレベルで アダプタ を作成することです。
最先端のエッジを維持することが重要な場合は、アプリケーションの一部をさまざまな速度でデプロイする方法が必要です。これが、オプション1としてマイクロサービスソリューションを含めた主な理由です。