Question

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

每个应用程序都定义了一个“服务”接口，该接口由它将处理的请求和预期的目标组成。

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

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

Answer 4

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

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

Answer 5

我听说James Gosling说可以在COBOL中实现SOA。

如果您阅读Alan Kay自己对OOP起源的描述，它会描述一堆小型计算机，它们可以相互作用以执行有用的操作。

考虑这个描述：

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

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

我认为可以进行以下替换：

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

如果你主要考虑封装，信息隐藏，松散耦合和黑盒接口，那么就会有很多相似之处。如果你陷入多态，继承等困境，你就会想到编程/实现而不是架构，恕我直言。

Answer 6

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

如果他们不被允许保留状态，那么他们就像你所说的那样 - 运营商关于数据。

听起来您可能将系统划分为太多服务。你是否有书面的，共同商定的划分标准？

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

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

6 个答案: