密接に結合された設計を改善するのに役立つ

Question

特定のBPMベンダーと連携する社内エンタープライズアプリケーション（EJB2）があります。社内アプリケーションの現在の実装では、ベンダーのAPIによってのみ公開されるオブジェクトを取得し、APIの公開されたメソッドを使用してそのオブジェクトを変更します。

私は何とか内部オブジェクトをこの外部オブジェクトにマップする必要があると思っていますが、それは単純すぎるように思えますし、これを行うための最善の戦略についてはあまりよく分かりません。過去にこのような状況をどのように処理したかについて、誰かが何らかの光を当てることができますか？

私はこのベンダーのソフトウェアを「ブラックボックス」にしたいので、必要に応じて簡単に置き換えることができます。どのように内部オブジェクトをこの公開されたAPIオブジェクトにマップするかは、設計上の観点から最良のアプローチは何でしょうか？私の社内アプリケーションはAPIとまだ話している必要があるので、両者の間にいくつかの依存関係が存在することを覚えておいてください。しかし、私はjunitを使ってこのソフトウェアとは別にテストすることもできます。

おかげで、 ジェイソン

Answer 1

サービスレイヤのインターフェイスを作成します。内部的にすべてのコードがそのレイヤで動作します。その後、そのインタフェースを使用するクラスを作成し、サードパーティ製のapiメソッドおよびapiファサードを呼び出します。

すなわち

interface IAPIEndpoint { 
    MyDomainDataEntity getData(); 
} 

class MyAPIEndpoint : IAPIEndpoint { 

    public MyDomainDataEntity getData() { 
     MyDomainDataEntity dataEntity = new MyDomainDataEntity(); 
     // Call the third party api and fill it 
     return dataEntity; 
    } 
} 

それは常に、あなたのアプリケーションドメインに侵入彼らのファンクを得ることはありませんし、必要に応じてあなたが入れ替えることができるように、サードパーティのAPIを行うインタフェースすることをお勧めします。異なるサービスを完全に使用する別のクラス実装を作成することができます。

は、それが進むべき道である複数の実装にまたがるとき、あなただけのインターフェイスに基づいて自分のものを作る

IAPIEndpoint endpoint = new MyAPIEndpoint(); // or get it specific to the lang you are using. 

を呼び出すコードでそれを使用します。それはTDDでもうまくいきますので、あなたのドメインコードをサードパーティのAPIから完全に分離して調べることができるローカルのテストにインターフェイスを入れ替えることができます。

Answer 2

抽象化。 DALを実装してください。これは、内部から外部への移行を提供します。

ベンダーを切り替えると、内部は貴重なままで、ベンダー固有のコードを変更することができます。ベンダが同じ機能性とデータタイプを提供していると仮定します。

Answer 3

私はここで黒い羊になり、YAGNIの原則を支持します。問題は、今すぐ抽象レイヤーを実行すると、サードパーティ製のAPIと似ていて、冗長レイヤーになるということです。将来の第2ベンダーのAPIがどのように見えるかわからないので、あなたは何を考慮する必要があるのか​​分かりません。将来のポートでは予期せぬ違いのためのリワークが必要になるでしょう。

テストフレームワークが必要な場合は、BPMベンダーと同じAPIを使用して独自のテスト実装を行うことをお勧めします。さらに、評判の良いほとんどのAPIプロバイダは、テストのために何らかのサンドボックスモードを提供しています。もしそうでなければ、あなたは1つを求めるべきです。