一个服务本身就是一个服务生命体，需要独立发展。我们在编制SOA设计模式目录时，了解到不仅在设计阶段，甚至是服务生命周期的后续维护阶段也会涌现许多模式。

　　很多项目都会有一个普遍场景：

　　·在SOA实施的初期，服务的模拟和设计会受到基础设施和技术的制约。这些限制条件迫使我们缩小服务组合的规模，降低跨服务信息交流的程度。结果，每个服务包含了更多的逻辑并且颗粒度更为粗糙。

　　·基础设施得到了提高（主要是因为新平台进行了升级或是拥有了更好的软件等）。我们的服务组合是由粗颗粒服务构成的，并通过就环境的参数交付这些服务。但是，我们意识到服务可以拥有细颗粒度（性能更为优良，构成更为有效）因为基础设施可以支持规模更大的服务组合。
　
　　为了适应当前的这一情况，在服务被部署到一个或者是多个细颗粒服务中后，服务分解模式提供了一种分裂服务的技术。

　　当然，许多版本控制和变动管理的参与者都对这个方法很感兴趣。我们怎样才能分离带有合同的服务，而又不会令使用这些服务的客户程序受到影响呢，同时实时运行还要依赖服务的现状？

　　为了解决这些问题，我们需要其它的SOA设计模式来帮助我们解决服务结构模式问题。

　　·代理功能——当逻辑从一个服务转移到另一个服务当中时，我们就会利用这个模式维持服务合同所描述的原有功能。

　　·服务表层—为了支持准许代理功能，这一多用途模式可以被用来建立数据处理的表现层，连接原有服务和新服务。表面组件可以促进新建服务的相应功能。这样一来，便可以代表原有服务的客户，成为服务客户。

　　当原始服务逻辑移到新地方时，很可能产生行为变化。如果同时实施以上两个模式和服务分解模式，表层逻辑就可以弥补这种变化。

　　要想成功分解一个服务，需要一个必要的前提即得出的颗粒度更为细致的服务要有完全不同的功能背景。当模拟并设计这些新服务时，所有可用的服务定向原则和模式都应该被看做是带有其它新服务的原则和模式。同时还需要实施像服务规范化这样的基础模式，以确保新服务可以和现有服务清单上的其它服务结合在一起。

　　服务分解的后续时期还有一个共同问题，但是既定的一套功能无法和新服务的功能环境完全吻合。这意味着新服务只能要求原始服务功能代表一部分。

　　这里有几个解决这个问题的方法，包括一个代理功能混合应用，在这个应用中原始服务保留了一些逻辑但是还是会呼叫处于其它位置的新服务。但是，在原有服务的建模初期，还要考虑另外一个模式，以便满足将来的分解要求。这个模式叫做被分解功能，主要是让我们预先思考，一个既定的粗颗粒服务环境是如何被分成众多新颗粒环境的，并且和主要服务功能相对齐。

　　在SOA设计模式目录中，服务分解模式在分类上是一种治理模式，尽管它和服务设计之间的联系更多。所有的这些模式都可以帮助扩充现有的服务集合（支持服务组合和服务重组），并使其更为合理化。