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

Question

最近，我的公司对面向服务的架构 (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 对象实际上只是一个结构，因为所有业务规则都隐藏在服务中。

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

Answer 1

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

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

Answer 2

SOA 是一种用于系统或应用程序之间通信的良好架构。

每个应用程序都定义一个“服务”接口，其中包含它将处理的请求和预期的响应。

这里的关键点是定义良好的服务和定义良好的接口。 就 SOA 而言，您的服务的实际实现方式并不重要。

因此，您可以自由地使用所有最新、最好的 OO 技术或任何其他适合您的方法来实现您的服务。 （我见过极端的情况，其中“服务”是由实际的人类在屏幕上输入数据来实现的——但一切仍然是教科书上的 SOA！）。

Answer 3

我确实认为 SOA 仅对外部接口有用（一般来说，对于公司外部的接口），即使如此，只有在性能并不真正重要的情况下，您才不需要按顺序传递消息。

有鉴于此，我认为它们可以共存。 使用 OO 哲学让您的应用程序保持工作和通信，并且仅当需要外部接口（向第三方）时，才通过 SOA 公开它们（这不是必需的，但它是一种方式）。

我确实觉得 SOA 被过度使用，或者至少 SOA 架构被频繁地提出。 我确实不知道有哪个大型系统在内部使用 SOA，而且我怀疑它们可以。 它看起来更像是一种你可能只是用来做混搭或简单的天气预报类型请求的东西，而不是在其上构建严肃的系统。

Answer 4

我认为这是对面向对象的误解。 即使在 Java 中，方法通常也不是对象的一部分，而是类的一部分（甚至这种“成员资格”对于面向对象来说也不是必需的，但这是一个不同的方法）主题）。 类只是类型的描述，因此这实际上是程序的一部分，而不是数据。

SOA 和 OO 并不矛盾。 服务可以接受数据，在内部将它们组织成对象，对它们进行处理，最后以所需的任何格式返回它们。

Answer 5

我听 James Gosling 说过可以用 COBOL 实现 SOA。

如果您读过艾伦·凯 (Alan Kay) 自己对 OOP 起源的描述，它描述了一堆小型计算机通过交互来执行一些有用的操作。

考虑这个描述：

你的X应该由Y组成。 每个 Y 应该负责一个概念，并且应该可以根据其接口进行完整描述。 一个 Y 可以通过消息交换（根据其指定的接口）要求另一个 Y 做某事。

在某些情况下，X 可以由 Z 实现，Z 根据其接口进行管理。 不允许任何 X 直接访问另一个 X 的 Z。

我认为以下替换是可能的：

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

如果您主要考虑封装、信息隐藏、松散耦合和黑盒接口，那么两者之间有相当多的相似之处。 如果您陷入多态性、继承等困境，那么您正在考虑编程/实现而不是架构，恕我直言。

Answer 6

如果您允许服务记住状态，那么它们就可以被视为调用时间可能很慢的大对象。

如果不允许他们保留状态，那么他们就像你所说的那样——数据操作员。

听起来您可能将系统划分为太多服务。 你们是否有书面的、双方同意的划分标准？

采用 SOA 并不意味着抛弃所有对象，而是将系统划分为可重用的大块。