最近,我的公司对面向服务的架构(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
对象实际上只是一个结构,因为所有业务规则都隐藏在服务中。
我可以同时拥有丰富的功能类和可重用的服务吗?