oop - 面向服务与面向对象——它们可以共存吗？

Question

人们对 Service-Oriented Architecture 很感兴趣(SOA)最近在我的公司。每当我试图了解如何使用它时，我总是会遇到心理障碍。粗略地说:

• 面向对象说:“将数据和操作数据(业务流程)的方法放在一起”；

• 面向服务说:“将业务流程保留在服务中，并向其传递数据”。

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

我的问题是:什么模式、架构、策略等允许 SOA 和 OO 协同工作？

<小时/>

编辑:“OO 用于内部，SOA 用于系统边界”的答案很棒且有用，但这并不是我想要的。

假设您有一个 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

在面向对象的情况下，业务逻辑(以及得益于 ActiveRecord 模式的实体感知)被烘焙到 Account 类中。在 SOA 情况下，Account 对象实际上只是一个结构，因为所有业务规则都隐藏在服务中。

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

Answer 1

我的观点是，SOA 在宏观层面上很有用，但每个服务可能仍然足够大，需要多个内部组件。内部组件可能会受益于 OO 架构。

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