SOA与DDD

紧跟着SOA之死以及觉醒吧！SOA，关于“是什么组成了SOA”的争论仍然如火如荼。Phillip Calcado提出了一个相当根本性的问题：什么是服务？

关于SOA与服务的定义多如牛毛，并非所有关于这一话题的内容我都是完全赞同的。在前SOA时代我曾使用过多种不同的分布式组件，在我看来，人们用以定义SOA的东西与基于组件设计中的现有资源却并无多大差别。

在这一例子中，架构没能反映业务。当然，当你是一个昂贵产品的供应商时，对于哪些可以以及如何暴露有着一定的约束。如果仅仅关注问题的技术方面，我建议，如果我们有意地让业务人员在设计战略时将计费作为他们要使用的特性考虑进来的话，我们就可以让它成为一等公民。

在这一讨论中，Phillip作出这样的声明：

SOA背后的技术与往昔的基于组件设计技术非常相同。我们现在用服务所做的很多东西都可以用组件技术来完成。主要的不同之处是思维而已，组件通常是技术人员创建并使用的。服务有着更广的用户基础。

这与Jack van Hoof所说不谋而合。他也提出了同样的问题。

那么，一个软件组件是否是一个服务，而CBD（基于组件的开发）与构建面向服务的架构是否也是等同呢？并不完全，还有另一方面：SOA中的一个服务是一个软件组件（以对SOA现有的理解来看），但却是有着强业务功能约束的组件。SOA是基于组件架构的一个实例。所以构建SOA始终与CBD有关，但以我们对SOA的理解来看，CBD却并不是总是与构建SOA相关。

但Phillip走得更远，并相信架构需要以一种开发者和利益相关者（不是开发者利益相关者吗？）共同都能理解的语言来表示。

就算只是发生在设计层面上，要为系统架构提供一个普遍的语言也需要一些工作。然而，由于架构性组件通常直接影响到业务——它们更实在一些——而大多数类和对象并非如此，我觉得在架构层面上基于领域驱动设计的原则来工作也许还更容易一些。

这正是领域驱动设计施展身手之处：“一个服务应当实现一个用户可以理解的概念。” Phillip接着使用了一个电子邮件的例子来说明他的意图，但其中心思想是应用里的服务应当符合终端用户的预期，而不是开发者的想法或者低层次系统的供求。

其要义在于，把这个服务定义成用户对其任务思考方式的一部分。只有API用户完全理解你定义服务所用到的语言，你才能达到开放你的系统这一目的。就算你为他们提供了一份详尽的手册，但在他们对你服务思考的方式（通常受你用户界面外观的影响）与你如何实现它之间仍需进行大量的转换。

但最后让我们来看看OASIS SOA 参考模型标准是如何定义一个服务的组成的，它反应了大部分Philip与Jack的观点：

“服务”这一名词在字典中定义为“一方为另一方执行的工作（某种功能）。”然而，服务，作为一个被广泛理解的术语而言，同样还包括了以下这些相关含义：

• 为另一方执行工作的能力
• 为另一方提供的工作规范 
• 为另一方执行工作的要约

这些概念强调了能力与运用这些能力之间的区别。尽管需求与能力都是独立于SOA而存在的，在SOA中，服务才是将需求与能力两者结合起来的机制。

在Phillip博文的评论部分里，对于他的描述是否是正确的也有不同的意见，其中一条评论是这样的：

我不认为有谁可以说你的描述就是SOA的正确定义了，就像每个人都有它自己的真相一样，这里不存在一个唯一的真相。但这篇文章是目前我所见过的SOA的定义中最有用的了。

但也有人并非如此确信：

我想关于SOA的观点存在自有其道理，我个人而言倒更宁愿谈谈良好的专注于业务的SOA（也许是Steve Jones风格的），再深入到领域模型。通过这样做，我们能够从DDD（UL）中直接获取一些思想，并能用其它的一些思想来改造/描述我们的服务（上下文映射/有限的上下文/等等）。但我仍然希望很快有谁能够站出来为SOA也编写一本类似的书。

很明显，只要关于“什么构成了服务”的不确定仍然存在，我们怎么能指望SOA的交付？或者这只是一个不相干的个案而已，每个人实际上都理解了“什么是一个服务”？。

查看英文原文：SOA and DDD