Metaphor: bridge to the unknown. – Object thinking
就像Object thinking那本书中所说的那样，“比喻： 通向未知的桥梁”，同样，我们在学习新技术和新名词的时候也可以通过打比喻，作对比来达到知晓的目的。那么比喻为什么能够帮助我们呢？那是因为，人们总对于自己熟悉的事物比较能够理解。通过比喻和对比，在新事物与旧事物之间建立快速联系，就能够帮助我们了解新事物的特征。
好了，本文的读者不需要太多的技术功底，只需曾经使用OOD进行过系统设计过即可，当然，如果你对OOP, OOA和Web Service有所了解，那就更好了；如果你已经对SO了解，那么不必读下去了。
我们总是在改变，我们的世界如此，我们的系统也是如此。那么当SO出现在我们的世界里，我们就会问了，”OO被淘汰了吗？”，“SO能够解决OO解决不了的问题吗？”
如果第一个问题答案为是，而第二个问题答案为否，那么SO就没有任何存在的必要了，换句话说，我也不在这给大家介绍了。
好，“OO被淘汰了吗？”首先我们来看一个图
这个图很清楚地表明了我们使用OO进行系统开发的特征，也就是说，其实我们的系统就是通过将不同的对象进行引用而形成的。
好，我们再来看另一个图
那么有人会说了，SO不过是OO的一个扩展吧？
如果说系统是真理的话，那么OO和SO是系统在设计世界中不同的模型折射，因为我们都知道，真理是立体的，它有不同的呈现方式，我们每个人看到它的不同的方面。
好像目前为止，我没有对上述问题做出任何正面的回答，其实答案已经有了，那就是“否”，OO没有被淘汰，我们只是对于系统的认知更进了一步，我们看到了系统的另一面。SO也不是对于OO的扩展，因为就好比宏观经济学和微观经济学之间的关系，你不能说前者是对于后者的抽象，而后者是对于前者的扩展一样。
不同的人看同一个事物，会有不同的观点和印象，对于一个实现了的系统而言，程序员因为看到自己写的代码只不过是些贴上标签的C#类，因此他们坚持认为这是OO; 架构师会说，我设计的是符合SOA所有的特征的，因此我坚持认为这是SO。这也就是现在对于SO的认知如此的模糊的原因。
通过这两张图我们可以清楚地知道，SO和OO都是系统的在软件模型设计中的一个影射，因此不存在谁淘汰谁的问题，他们是可以共存的，我们的系统中既有对象的存在，也有服务的存在，面向什么的设计，编程都是一个分析，实现者的哲学观的问题。
好了，我们知道OO不会被淘汰，后果不严重，大家很欣慰。
那么，“SO能够解决OO解决不了的问题吗？”
对于这个问题，让我们来了解一下SO的基本原则，这就是 边界强制性、自制性、契约性以及Policy-based兼容性。接下来逐一解释。
边界强制性
在服务的世界中，每个服务之间的边界是清晰的，并且是强制的。对于一个系统，你一眼看过去，有多少个服务在那里都很清楚。而且，服务边界是通过消息来勾连的。我们可以把消息看成水，把服务看成鱼，把系统看成鱼缸。每条鱼都是独立存在的，通过水来组合成一个鱼缸。
在SO系统中，跨过每个服务的边界进行调用是有成本的，我们会很清楚；但是在OO的分布式系统中，我们很容易把一个远程的对象当作本地对象来对待，很可能导致远程对象被过度使用。这就好比你到超市最好列个购物清单，以免超过预算；而到一般的便利店则不必担心这个问题。
自制性
每个服务内部都是自制的。也就是说，系统中的某个服务被部署，升级和修改，都不会影响到整个系统被重新建立。
而在OO建立的分布式系统中，我们可以知道，某个对象库往往是以原子级别单位被部署，升级和修改的，那么由于耦合的程度高，并且对象库之间的调用没有明确的边界强制性，就会导致整个系统需要重新建立。
大家有多少次觉得，维护一个现有的系统比重新写一个同样的系统要来得困难呢？
契约性
服务之间通过议定的纲要来传递数据通过契约来特定化行为。那么OO的世界里呢？那是通过类型和类来传递的。
某个服务对外交换信息的时候，仅仅告诉别的服务，“我能够做到什么”，“我仅能够做那些我已经声明过的事情”；也就是说，服务是根据自身的能力来暴露数据和契约的。
OO则要求整个系统类型的同一化, 而这个同一化的过程是通过类型和类来恒定的。
Policy-based兼容性
Policy干了什么? 呵呵, 它抽象了一下。 （记得C++沉思录中说过一句经典的话，那就是OO真正的威力在于抽象。）那么它抽象了什么？它把服务与交互之间的约束抽象了出来。难理解？这么想，举个例子，服务为什么能够和传统的Web服务交互？就是因为大家都基于相同的策略。
那么，SO又有些什么优势呢？
最大的好处就是系统松耦合，那就有了弹性和适应性。我们可以这么想，把SO想象成一个巨大的架构模式，它有一些规则，它把原有的在被反复使用的模式融合起来，让我们在架构系统的时候基于一个准确的大前提和一套简单的规则，而自由发挥。
现在可以来回答这个问题了，SO能够解决OO不能够解决的问题，从宏观上说，SO给与架构系统更简单的规则，大家都知道，简单意味着更不容易出错，而OO给与我们过于自由的尺度，这也是为什么现有多数系统糟糕、杂乱的原因；从微观上说，SO甚至比OO提供给我们更多的设计自由，我们能够将现存所有的技术，基础结构统统放到我们的方案中，而不必关注技术和基础结构的实现细节。
