做软件设计的，就算没有机会仔细研究过
设计模式，多少都听说过“四人帮(Gang of Four)”的《
Design Pattern》。“
设计模式”的四个伟大的作者，把面向对象软件设计的代码复用推向一个新的高度，第一次将
设计模式规范化，并提升到理论高度。虽然软件
设计模式针对的是代码片段的复用，而
SOA实施中讨论的是服务的复用，是软件开发中两个不同层次的问题，但是因为面向对象的软件设计也是
SOA的一大支柱，所以这里有共性，
设计模式许多好的思路，在
SOA的服务复用中值得
借鉴。
在面向对象软件设计中，具体的应用软件是用许许多多的类(Class)代码来构建。
设计模式理论就是指导如何有效的组织类代码形成具体应用软件。譬如说，通过Strategy Pattern定义一系列的算法封装类，使它们可相互替换，使得算法的变化可独立于使用它的客户；通过Composite Pattern将对象组合成树形结构以表示部分-整体的结构，让客户对单个对象和复合对象的使用具有一致性。在
SOA实施中，具体的应用系统由许多按照良好接口定义的服务构成，通过何种有效的方式来组织这些服务，同样需要理论指导，或者说同样可以定义
SOA的模式。譬如说，能否定义有效的模式把低层次的服务组装成高层次的服务，同时兼顾低层次服务的可替换性，以保持足够的业务灵活度。
在定义
SOA模式的时候，还可以
借鉴设计模式的诸多原则。譬如说，面向对象软件设计中的里氏替换原则(
Liskov substitution principle)，对父类的调用同样适用于子类(
Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.) 。同样的原则，对于
SOA也是非常有意义的，在原有服务基础上扩展功能的服务应该保持良好的兼容性，让原有系统的服务——消费关系无需改变就能适用新服务。以此为例，许多成熟原则的运用能加速
SOA的演进。
等同
设计模式的作用，定义
SOA的模式，其实是利用模式来共享专家知识。
SOA作为新生事物，刚开始的时候，只有少数经验丰富的技术专家和业务专家能够掌握其精髓，熟练运用到具体的业务领域，构建优秀的
SOA系统。如果从专家们实施的成功项目中提炼出
SOA运用的最佳实践，也就是“模式”，通过广泛的推广模式运用，就相当于快速复制专家经验。一方面，经验不够丰富的人不会因为白手起家而无所适从，他们可以基于模式做
SOA实施，提高成功率，在学习专家经验的同时提高自身水平；另一方面，模式让
SOA作为专家知识载体，在广泛的运用过程中，有机会进一步得到修正和提升，千锤百炼后最终更加完善适用。
那么，谁会推动模式的定义呢？作为专家知识载体的模式，可能会分别来自于
SOA平台工具厂商，开发社区，以及企业。这三个来源对模式定义的侧重点会有所差异：平台工具厂商会定义最大限度利用其平台特性的模式，并辅以相应的开发工具；开发社区往往讨论通用的模式，帮助形成定义模式的标准；企业的模式定义最实用，而且和行业应用紧密结合。不管何种来源，模式定义殊途同归的结果是加速
SOA系统构建知识的普及。
