外部システムと統合するためのベストプラクティスについての簡単な質問。
私たちは、私たち自身のオブジェクトによって表される会社を扱うシステムを持っています。また、Organizationオブジェクトを返すSOAPを介した外部システムを使用します。それらは非常に似ていますが、同じではありません（私たちのものはそれらのサブセットです）。
私の質問は、FAcadeを介してSOAPサービスをラップして、Companyオブジェクトのみをアプリケーションに返すか、別のタイプのオブジェクト（OrgCompanyなど）を返すか、コードでOrganizationオブジェクトを使用するかです。
SOAPサービスとOrganizationオブジェクトは、私たちが管理できない外部の会社（銀行）によって定義されています。
アドバイスや正当化は大歓迎です。
私の2セント、アプリケーションに外部オブジェクトを導入することは常に問題です。特にメンテナンス中。小さなサービスの変更は、アプリケーションの大きなコード変更につながる可能性があります。
外部サービスとアプリケーションの間にレイヤーの抽象化があることは常に良いことです。外部サービスオブジェクトをアプリケーションドメインオブジェクトに変換し、アプリケーション内で使用するサービスレイヤーを作成することをお勧めします。明確な分離/デカップリングは、メンテナンスに大いに役立ちます。
下の図は、上記の内容を示しています。
他社がコントロールしているオブジェクトを使用するのが良い状況とは思えません。最初にすべきことは、それらのオブジェクトを自分のものに橋渡しすることです。また、独自のオブジェクトを持つことで、接続先のサード パーティが提供する機能を超えて機能を拡張できます (たとえば、将来、複数の Company オブジェクト プロバイダーと対話する必要がある場合)。
Adapter パターンを見てください。
ここでの決定は、アプリケーションで外部コードの依存関係を管理する方法です。決定に影響を与えるいくつかの要因: 1) API はどのくらいの頻度で変更されますか? また、変更の予想される性質は何ですか? 2) 依存関係以外でのアプリケーションの有用性は何ですか? SOAP サービスの依存関係を削除した場合でも、アプリは目的を果たしますか?
防御的なアプローチは、SOAP サービスの周りにファサードまたはアダプターを構築して、コードがオブジェクト モデルのみに依存するようにすることです。これにより、多くの制御が可能になり、コード/ロジックとサービスの間の結合が比較的緩くなります。このコントロールの代償として、SOAP コントラクトが変更されると、通常はコードのレイヤーも変更する必要があります。
別のアプローチは、WSDL から取得したオブジェクトを直接使用することです。これは、クライアント コード間でアプリケーションに一定レベルの間接性を導入する意味がない場合に役立ちます。つまり、アプリケーションが別のシステムへのフィーダーにすぎず、アプリの要点は組織オブジェクトをシステムに詰め込むことです。 JMS パイプラインまたは類似のもの。SOAP API コントラクトが変更されず、アプリの出力があまり変更されないことが予想される場合、追加の間接レイヤーを導入すると、長期的にはコードベースの可読性が妨げられます。
私の経験では、ほとんどの j2ee 開発者は、アプリケーションの性質と、アプリケーション ロジックをデータ ソースの詳細から分離したいという理由から、前者のアプローチを取る傾向があります。
お役に立てれば。
Sridhars の提案を支持します。外部サービス オブジェクトをアプリケーション ドメインに変換するために Dozer を使用できることを追加したいと思います。
ここではエンタープライズ サービス バスアーキテクチャが役立つかもしれません
その主な用途は、異種の複雑なランドスケープのエンタープライズ アプリケーション統合です。
（ウィキペディアより）
オープンソースのソリューションを探しているなら、オープンソースのMuleをチェックしてみてください。
通常、私は常に、外部で定義されたドメイン オブジェクトを内部表現に適応させます。
また、外部ベンダーが新しいリリースを作成した場合に問題を迅速に明らかにする、外部ドメイン オブジェクトに対する包括的な一連のテストも作成します。