关于与外部系统集成的最佳实践是什么的快速问题。
我们有一个系统来处理我们用自己的对象代表的公司。我们还通过返回组织对象的 SOAP 使用外部系统。它们非常相似但不相同（我们的是它们的子集）。
我的问题是，我们是否应该通过 Facade 包装 SOAP 服务以便仅将 Company 对象返回给我们的应用程序，或者我们是否应该返回另一种类型的对象（例如 OrgCompany），或者甚至只是在我们的代码中使用 Organization 对象。
SOAP 服务和组织对象由我们无法控制的外部公司（银行）定义。
非常感谢任何建议和理由。
我的两分钱，将外部对象引入应用程序始终是一个问题。尤其是在维护期间。一个小的服务更改可能会导致应用程序中的大代码更改。
在外部服务和应用程序之间有一个抽象层总是好的。我建议创建一个服务层，它将外部服务对象转换为您的应用程序域对象并在应用程序中使用它们。清晰的分离/解耦有助于维护。
下图描述了上述内容。
我想不出使用其他公司控制的对象的任何情况。您应该做的第一件事是将这些对象连接到您自己的对象中。此外，通过拥有自己的对象，您可以将它们的功能扩展到您连接的第三方提供的功能之外（例如，如果将来您需要与多个公司对象提供者交谈）
查看适配器模式。
您在这里的决定是您希望如何管理应用程序中的外部代码依赖项。一些影响您决定的因素： 1) API 多久更改一次，更改的预期性质是什么？2）您的应用程序在其依赖之外的用途是什么？如果您删除了 SOAP 服务依赖项，您的应用程序是否仍然有用？
一种防御方法是围绕 SOAP 服务构建外观或适配器，以便您的代码仅依赖于您的对象模型。这为您提供了很多控制权，并且代码/逻辑与服务之间的耦合相对松散。您为此控件付出的代价是，当 SOAP 合同发生更改时，您通常还必须更改代码层。
另一种方法是直接使用从 WSDL 获得的对象。当在您的应用程序中引入客户端代码之间的间接级别没有意义时，这是有益的，即您的应用程序只是一个不同系统的馈送器，而应用程序的全部意义在于将组织对象填充到一个JMS 管道或类似的东西。如果 SOAP API 契约从不改变，并且您不希望应用程序的输出发生太大变化，那么引入额外的间接层只会长期阻碍代码库的可读性。
根据我的经验，大多数 j2ee 开发人员倾向于采用前一种方法，这既是因为他们的应用程序的性质，也是因为他们希望将他们的应用程序逻辑与数据源的细节分开。
希望这可以帮助。
我支持 Sridhars 的建议，我只想补充一点，以便将外部服务对象翻译到您的应用程序域，您可以使用 Dozer：
我通常总是将外部定义的域对象调整为内部表示。
我还针对外部域对象创建了一套全面的测试，如果外部供应商发布新版本，它将快速突出任何问题。