oop – 服务取向和对象取向 – 他们可以共存吗？

在我的公司最近对 Service-Oriented Architecture(SOA)有很多兴趣。每当我试图看看我们如何使用它，我总是与一个心理块。粗俗：

>面向对象说：“保持操作数据(业务流程)的数据和方法在一起”;
>服务导向说：“将业务流程保留在服务中，并将数据传递给它”。

先前尝试开发SOA的尝试最终将面向对象的代码转换为数据结构和单独的操作它们的过程(服务)，这似乎倒退了一步。

我的问题是：什么样的模式，架构，策略等允许SOA和OO在一起工作？

编辑：答案说“OO的内部，SOA的系统边界”是伟大的和有用的，但这不是我得到的是什么。

假设您有一个Account对象，其具有名为Merge的业务操作，将其与另一个帐户合并。典型的OO方法如下所示：

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

而我看到的SOA等效看起来像这样：

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

在OO情况下，业务逻辑(和实体感知由于ActiveRecord模式)被烘焙到Account类。在SOA的情况下，Account对象实际上只是一个结构，因为所有的业务规则都埋在服务中。

我可以同时拥有丰富的功能类和可重用的服务吗？

我真的认为SOA只对外部接口(一般来说，对公司外部的接口)有用，甚至在性能并不重要的情况下，你不需要有序的消息传递。

鉴于此，我认为他们可以共存。使用OO理念使您的应用程序保持工作和通信，并且只有当需要外部接口(第三方)时，通过SOA公开它们(这不是必需的，但它是一种方式)。

我真的觉得SOA被过度使用，或者至少有SOA的架构被频繁提出。我真的不知道任何使用SOA内部的大系统，我怀疑他们可以。似乎更多的是你可能只是用来做混搭或简单的天气预报类型的请求，而不是建立严重的系统。