这种简单的限制从长远看将增加服务的再利用性。随着时间的推移，这个服务能够有效地随着业务的变化而发展，扩大或者甚至取代其基本的资源，同时最大限度地减少这些改进对外部服务消费者的影响(因为由于合同集中化，他们不能直接连接到这些资源)。这个服务的寿命越长，它的长期再利用的潜力就越大。
因此，虽然逻辑集中化不需要合同集中化，但是，它肯定会从其应用程序中受益。事实上，当这两个基础的方式一致地应用到一个服务目录(服务集)中的时候，他们建立了一个非常能够推广业务灵活性的环境。因为这些服务能够重复地再利用，我们要求对每一个新的解决方案建立较少的冗余的逻辑(减少解决方案交付的时间和成本)。因为这些服务只能通过其合同访问，我们避开了建立很难改变的整合渠道。因此，我们最终将建立能够有效地重复利用的服务并且与业务一起发展。
当然，SOA的战略目标要实现的东西比仅仅使用这两个模式多得多。然而，这是SOA设计模式建立的基础，对于取得SOA的成功是至关重要的。甚至最强大的、可升级的和高级的基础设施也不能帮助你把设计遭到的服务转变为高价值的IT资产，在不断变化的商业环境中不断带来回报。服务需要从头开始设计并且预测和适应变化。这就是所谓的面向服务的。
在我们做结论之前，让我们简单地介绍一下模式应用顺序和模式语言的概念。我们仅解释了合同集中化如何支持逻辑集中化的。但是，当设计服务时，你首先采用哪一种模式呢?虽然没有绝对的规则，但是，你可能会有偏爱。例如，当同时建立一个服务集模型的时候，为了恰当地把服务分为独特的逻辑单元，受使用逻辑集中化是有意义的。然后，你可以使用合同集中化。这样，这些单元(服务)的每一个部分都将得到一个技术合同，作为正式的进入点。
我们刚才解释的是模式应用顺序在一个具体顺序中应用的两个模式。一个模式目录是理想地构造的，因此，你能够根据你们的要求、偏爱和局限性提出许多创造性的应用顺序。有些目录甚至提供了推荐的模式顺序，许多单个的模式被认为是经过证明的设计解决方案。这个应用顺序本身也被认为是经过证明的。
把许多模式结合到无止境的顺序中的自由使一个模式目录不仅仅是设计模式的记录文件，而是一个“模式语言”。同任何书面语言一样，你有能够组成一个句子的词汇。这些句子能够进一步组成一段话、一篇文章等等。人们可以用同样的方式想象一个模式语言。根据你的技能水平，当你拿笔在一张纸上写字的时候，你可以写出一个伟大的文学作品，也可以写出不伟大的文学作品。同样，使用模式语言工作的关键取决于你的知识和对模式本身的理解。通过理解模式是如何关联的，可以理解模式内部的主要部分
文章来源于领测软件测试网 https://www.ltesting.net/
