面向服务与面向对象 - 它们能共存吗？

最近我公司对面向服务的体系结构(SOA)很感兴趣.每当我试图看看我们如何使用它时,我总是遇到心理障碍.粗略地:

面向对象说:"保持数据和方法一起操纵数据(业务流程)";

服务导向说:"将业务流程保留在服务中,并将数据传递给它".

以前开发SOA的尝试最终将面向对象的代码转换为数据结构和单独的操作它们的程序(服务),这似乎是一个倒退.

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

编辑:答案说"OO for internals,SOA for system boundary"非常有用,但这并不是我所得到的.

假设您有一个Account对象,该对象具有一个名为Merge将其与另一个帐户组合在一起的业务操作.典型的面向对象方法如下所示:

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 API应该比内部API更仔细地定义,因为它是一个外部API.在此级别传递的数据类型应尽可能简单,没有内部逻辑.如果存在属于数据类型的某些逻辑(例如验证),则最好应该有一个服务负责在数据类型上运行逻辑.

SOA是用于在系统或应用程序之间进行通信的良好架构.

每个应用程序都定义了一个"服务"接口,它包含它将处理的请求和预期的目标.

这里的关键点是定义明确的服务,具有良好定义的界面.就SOA而言,实际实现服务的方式是无关紧要的.

因此,您可以自由地使用所有最新和最好的OO技术或任何其他适合您的方法实现您的服务.(我见过极端情况,"服务"是由实际人员在屏幕上输入数据而实现的 - 但一切仍然是教科书SOA!).

我真的认为SOA只对外部接口有用(一般来说,对于公司以外的人),即便如此,只有在性能不重要的情况下,您才需要有序的消息传递.

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

我真的觉得SOA过度使用,或者至少建议使用SOA过于频繁.我真的不知道在内部使用SOA的任何大型系统,我怀疑他们可以.看起来你可能只是用来做mashup或简单的天气预报类型请求,而不是构建严肃的系统.