複雑さを隠すレイヤーの実装

私が取り組んでいるプロジェクトの依存関係の一部として、いくつかのコアサービスを使用しています。私たちが大きな変更を加えることができないこれらのサービスは、大きな混乱です。呼び出すメソッドに応じて、パラメーター（および戻り値）を別のエンコーディング、ロケール、タイムゾーンに変換する必要があります。

これらのパラメーターは独自のコードの複数の場所で生成されるため、これらの変換は複数の場所で実行されます。私たちがそれらを私たちの側に渡す前に、それらを生成するときがあります。コアサービスでメソッドを呼び出す直前。混乱がコード全体に広がっているので、それを分離するためのレイヤーを導入したいと思います。

私の質問は、そのための最良のアプローチは何ですか。最初は、使用する必要がある各サービス/メソッドに対応するサービス/メソッドを作成することを考えました。これらのメソッドは、単に変換を実行し、コアサービスに委任し、戻り値の変換を実行します。しかし、これはどういうわけか扱いにくいようです。

その後、アノテーションを使用することを考えましたが、使用方法は完全にはわかりません。そして、私が理解しているように、理想的には、呼び出されたメソッドに注釈を付ける必要があります。たとえば、パラメーターを@converToUtcで注釈し、注釈の実装で変換を行うことができます。これは正しいです？もちろん、これは私たちのコードではなく、現在私たち以外のプロジェクトでこれらのメソッドを使用しているコードを壊すので、これは難しいことです。

この状況に最適なアプローチは何ですか？

あなたがしようとしていることは、ファサードパターンを実装することです。基本的には、コアコードにもっと単純な顔をしたいとします。コアクラスごとに1：1のマッピングを提供する一連のクラスを作成し、コアクラスの代わりにファサードクラスを使用することをお勧めします。コアサービスが大きなモノリシッククラスのメソッドの集まりにすぎない場合は、機能ドメイン（認証、データアクセス、ビジネス機能など）ごとに分解し、ドメインごとに異なるファサードを持つことを検討します。ファサードは、コードに意味のあるインターフェースを提示し、コアサービスとの通信に必要なすべてのマッピングとデータ変換を処理する必要があります。

あなたが直面している問題は、ソフトウェアエンジニアリングで頻繁に直面する一般的な問題のインスタンスです。抽象化/変換レイヤーを使用して特定の問題領域にツールを成形することです。

問題を解決するアプリケーションがあります。含まれ、管理され、相互作用するエンティティは、問題のドメインに属するエンティティです。それらはすべて、目前の問題を解決するのに役立つ用語で表現されており、時間を浪費してコードと関係のない変換でコードを汚染するのではなく、問題の解決に集中できるという点で「友好的」です。手元の問題。

あなたがすべてのコードを所有している限り、それはすべて問題がなく、面倒です。しかし、サードパーティのツール（ライブラリ）を画像に取り入れた場合、これらのツールは問題のドメイン内で動作するように作成されていない可能性が高いため、混乱を招き、面倒で、エラーが発生しやすい変換が必要になります。

通常起こることは、不便さは軽微であり、私たちは与えられたツールに対処するだけです。しかし、不便が大きいために日常生活がかなり困難になる場合、または最終結果が壊れやすく、エラーが発生しやすい場合は、コードと使用するツールの間に抽象化/変換レイヤーを導入することがあります。 。

これらの抽象化/変換レイヤーは、問題のドメインに関して表現されたコードへのサービスを提供し、サードパーティのツールに委任し、途中で必要なすべての変換を実行します。その際、これらのレイヤーは、使用するツールの特性を可能な限り抽象化する傾向があるため、理論的には、抽象化/変換レイヤーのみを変更することで、ツールを別のツールに置き換えることができます。コアロジックを変更する必要があります。

アノテーションについては、ここでどのように役立つかわかりません。まず、ターゲットインターフェイスのソースコードを所有していない場合、それらに注釈を追加することはできません。ただし、ターゲットインターフェイスに何らかの方法で注釈を追加できたとしても、注釈が機能するためには、コードとターゲットインターフェイスの間に中間層を埋め込む必要があります。これにより、呼び出しをインターセプトし、ターゲットメソッドの注釈を調べて、必要な変換。おそらく、Spring FrameworkやCastle ProxyのInterceptorなどを使用できます。 この中間層をコードとライブラリの間に魔法のように埋め込むメカニズムですが、従来の方法で中間層を簡単に記述し、ターゲットインターフェイスの詳細な知識を持ち、ハードコードされた変換を実行できるように思えます、簡単な方法で、ライブラリのインターフェースを抽象化してニーズに合わせます。

まず、あなた（またはあなたのチーム）は、あなた自身のコードで使用する「標準」フォーマットに同意する必要があります。例えば：

• エンコーディング：UTF-8
• ロケール：en_UK
• タイムゾーン：UTC

後になってから、依存関係から要求された形式に値を適合させるレイヤーを作成できました（扱いにくいとは思いません）。

Mike Nakisが言ったように、この問題を解決するために注釈を使用する利点も見当たらない。