设计模式多年以来一直是IT领域的一部分。甚至出现了一个完整的模式团体来培育新模式的发展，并且要围绕应该如何说明模式以及相关的事情制定一些指南。

　　这是正确的，模式之间是相互关联的。要制定设计模式，你需要理解这些关系。这些关系对于SOA是特别重要的，因为SOA的实施范围一般要大于传统的应用。因此，SOA设计模式要涉及面更广，因此影响力也越大。

　　首先让我们了解一些基础知识并且回顾一下一种模式如何与另一种模式相关联。有许多不同类型的关系。但是，最重要的两个关系式依赖关系和支持关系。

　　为了应用一种模式，你也许需要使用另一个模式(或者已经使用了另一个模式)。这是很简单的依赖关系。但是，这对于理解为什么存在依赖关系是很重要的。例如，在SOA设计模式目录中，有一种模式称作“逻辑集中化”。它实际上建立一个规则，按照这个规则，对于任何指定的解决方案逻辑的再利用部分来说，仅存在一个正式的服务。这就减少了冗余的风险，最大限度实现了在一个指定区域的服务的再利用潜力。它还构成了不可知环境的基础。这是一种设计模式，用于单个服务中，以便为它提供多功能的范围(因为它对于任何逻辑来说都是不可知的，因此它仅限于一个单个的目的)。

　　不可知环境和逻辑集中化共享培育服务中的再利用这个共同的目标。虽然逻辑集中化建立了独特的逻辑单元，但是，不可知环境将保证拥有再利用潜力的人和单元都将仅仅限制在多用途逻辑中。这样，它们就成了纯粹的再利用服务。

　　简言之，你会提出理由说不可知环境依赖于逻辑集中化，因为没有集中化独特的逻辑体，就很难把它们分成不可知的单元。在应用逻辑集中化模式之前，使用不可知环境是没有意义的。

　　我们提到的另外一种关系是一种应用模式支持另一种应用模式。因此，与依赖性的关系不同，在这个案例中没有直接的依赖关系。这就意味着这些类型的关系很容易错过。一种支持性的关系简单地意味着一种模式帮助实现另一个模式的目标或者最终目的。

　　我们重新看一下逻辑集中化的例子。这个模式的目标是培育在服务中的再利用。然而，应用程序集成的历史已经教会了我们通过多个点对点的集成渠道实现连接，达到一个灵活性的架构，使负担沉重的企业能够继续发展，特别是面对业务变化的时候。

　　这与逻辑集中化有什么关系呢?设想一个包含若干数据库和一个老式的系统的服务。既使我们集中了这个服务代表的逻辑，我们仍然不能做任何事情来阻止通过传统类型的集成渠道直接访问这些基本的资源。这正是合同集中化进入这个环境的地方。

　　合同集中化设计模式限制外部访问一个服务，访问出版的技术合同(或者接口或者API)。这就意味着外部程序或者应用程序(我们可以指服务用户)不能接触这些基本的资源，因为这个唯一的进入点是这个服务合同。

　　这种简单的限制从长远看将增加服务的再利用性。随着时间的推移，这个服务能够有效地随着业务的变化而发展，扩大或者甚至取代其基本的资源，同时最大限度地减少这些改进对外部服务消费者的影响(因为由于合同集中化，他们不能直接连接到这些资源)。这个服务的寿命越长，它的长期再利用的潜力就越大。

　　因此，虽然逻辑集中化不需要合同集中化，但是，它肯定会从其应用程序中受益。事实上，当这两个基础的方式一致地应用到一个服务目录(服务集)中的时候，他们建立了一个非常能够推广业务灵活性的环境。因为这些服务能够重复地再利用，我们要求对每一个新的解决方案建立较少的冗余的逻辑(减少解决方案交付的时间和成本)。因为这些服务只能通过其合同访问，我们避开了建立很难改变的整合渠道。因此，我们最终将建立能够有效地重复利用的服务并且与业务一起发展。

　　当然，SOA的战略目标要实现的东西比仅仅使用这两个模式多得多。然而，这是SOA设计模式建立的基础，对于取得SOA的成功是至关重要的。甚至最强大的、可升级的和高级的基础设施也不能帮助你把设计遭到的服务转变为高价值的IT资产，在不断变化的商业环境中不断带来回报。服务需要从头开始设计并且预测和适应变化。这就是所谓的面向服务的。

　　在我们做结论之前，让我们简单地介绍一下模式应用顺序和模式语言的概念。我们仅解释了合同集中化如何支持逻辑集中化的。但是，当设计服务时，你首先采用哪一种模式呢?虽然没有绝对的规则，但是，你可能会有偏爱。例如，当同时建立一个服务集模型的时候，为了恰当地把服务分为独特的逻辑单元，受使用逻辑集中化是有意义的。然后，你可以使用合同集中化。这样，这些单元(服务)的每一个部分都将得到一个技术合同，作为正式的进入点。

　　我们刚才解释的是模式应用顺序在一个具体顺序中应用的两个模式。一个模式目录是理想地构造的，因此，你能够根据你们的要求、偏爱和局限性提出许多创造性的应用顺序。有些目录甚至提供了推荐的模式顺序，许多单个的模式被认为是经过证明的设计解决方案。这个应用顺序本身也被认为是经过证明的。

　　把许多模式结合到无止境的顺序中的自由使一个模式目录不仅仅是设计模式的记录文件，而是一个“模式语言”。同任何书面语言一样，你有能够组成一个句子的词汇。这些句子能够进一步组成一段话、一篇文章等等。人们可以用同样的方式想象一个模式语言。根据你的技能水平，当你拿笔在一张纸上写字的时候，你可以写出一个伟大的文学作品，也可以写出不伟大的文学作品。同样，使用模式语言工作的关键取决于你的知识和对模式本身的理解。通过理解模式是如何关联的，可以理解模式内部的主要部分。