SOA 与 DDD

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

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

在 Phillip 看来，SOA 是关于“如何降低架构中的噪声”并且使用“作为业务的一部分”的组件。这让他得出 SOA 是领域驱动架构这一观点。Phillip 接着描述了他所参与过的一个业务约定，这一经历帮助他巩固了他对此的认识。事件是，一个客户认为应该购买一个新的计费系统，因为他们现在所使用的那个被隐藏在其它业务应用的后面，而没有被作为一等公民向其它应用暴露出来。

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

在这一讨论中，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