写点什么

SOA 与 DDD

  • 2009-03-06
  • 本文字数:1777 字

    阅读完需:约 6 分钟

紧跟着 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

2009-03-06 00:365539
用户头像

发布了 133 篇内容, 共 36.9 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
发现更多内容

系统架构知识-常识YES,能力NO

飞雪

架构师训练营 W4 作业

telliex

大型互联网应用架构中的主要技术,与其对应的业务问题

Ph0rse

<<架构师训练营>>第四周总结

R20114

架构师训练营第四周 - 作业

王权富贵

极客大学架构师训练营

架构师训练营第四周作业

努力努力再努力m

极客大学架构师训练营

互联网技术方案

allen

架构师训练营 W4 心得

telliex

大型网站架构演化历程

stars

第04周 设计系统架构 命题作业

Jaye

架构师训练营第四周心得

努力努力再努力m

极客大学架构师训练营

架构师训练营第四周作业

极客大学架构师训练营

第四周总结

changtai

极客大学架构师训练营

第 04 周作业

Jeremy

「架构师训练营」第 4 周作业 - 互联网技术

森林

架构师训练营第四周课程总结

狂奔嘀兔纸

极客大学架构师训练营

Week4-总结

龙7

系统架构

eazonshaw

极客大学架构师训练营

第四周作业

changtai

极客大学架构师训练营

课堂作业 week4

Dennis

作业04-互联网架构演化

梦子说

课程作业

第四周学习总结

iHai

极客大学架构师训练营

软件测试缺陷等级划分准则

海浪豆豆

软件测试

【架构师训练营】第 4周总结

花生无翼

Week 04- 作业二:学习总结

dean

极客大学架构师训练营

第四周总结

GAC·DU

架构学习第四周总结

云峰

第四周学习总结

麻辣

Week 04 学习总结

Jeremy

<<架构师训练营>>第四周作业

R20114

架构师训练营 第四周【学习总结】

小K

SOA与DDD_SOA_Mark Little_InfoQ精选文章