服务分解方式提供一种技术，可以在服务首次部署之后把这个服务分解为两个或者更多的详细的服务。
一个服务清单是服务的一个生命体。每一项服务经过一段时间之后都需要独立成长的自由。当我们编辑SOA设计方式目录的时候，我们了解到有许多方式不仅在设计的时候出现，而且还出现在实施之后的一项服务的生命周期的发展阶段。
下面是许多项目中反复出现的一种常见的情况：
1.当我们在SOA应用的早期阶段进行建模和设计的时候，我们会受到当前的基础设施和技术的制约。这些制约要求我们限制服务组成的规模和跨服务信息交换的范围。因此，每一个服务都包含更多的逻辑并且是粗颗粒的。
2.我们的基础设施将随着时间的推移而改善(因为新的平台升级或者为购买更好的硬件投入新的资金等)。我们现有的服务组合包括粗颗粒的服务。这些服务是按照比较老的环境的参数提供的。然而，我们现在认识到服务可以是更精细的并且能够更有效地实施和组合这些服务，因为这个基础设施能够支持更大的服务组合。
为了对这种情况做出反应，服务分解方式提供一种技术，可以在服务首次部署之后把这个服务分解为两个或者更多的详细的服务。
当然，这种方法会引起参与版本控制和变化管理的人们的不满。我们如何能够利用一个已经建立的合同在不影响消费者计划的情况下分解一个服务?消费者的计划一直使用这项服务并且已经建立了自己当前存在方式的非常真实的运行时间依赖性。
要解决这个问题，服务分解方式需要其它一些SOA设计方式的帮助：
·代理能力：当逻辑从一项服务转移到另一项服务的时候，这个方式能够用于保持原来的服务合同所表示的原来的能力。
·服务外表：为了支持实现的代理能力，这种多用途方式可以用来建立(在原来的服务逻辑中)一个处理的外表层，作为原来的服务和新的服务之间的纽带。这种外表层组件实际上会启动新创新的服务中的相应的功能，从而代表原来的服务的消费者作为这个新的服务的消费者。
·当与服务分解一起使用这两种方式的时候，这个外表的逻辑还会补偿行为的变化。原来的一部分服务逻辑在物理上转移到一个新的位置的时候可能会发生这种行为的变化。
服务分解取得成功的一个重要要求是最终产生的更精细的服务有独特的功能环境。当建模和设计这些新的服务的时候，所有可用的、面向服务的原则和方式必须与其它新的服务一起考虑。还需要使用服务正常化等其它基本方式保证新的服务与现有的服务目录中的其它服务一致。
然而，实施之后进行服务分解遇到的一个常见的问题是一套指定的功能也许明显地与新的服务的功能环境不一致。这就意味着一项新的服务也许只需要原来的服务功能的一部分功能。
还有许多处理这种问题的方法，包括一种代理功能方式的混合应用。在代理功能中，原来的服务保留了它的一些逻辑，但是，接下来仍然调用现在属于其它地方的新的服务。然而，在原来的服务的最初的建模阶段，我们还可以考虑其它的方式以应对未来的服务分解的需求。这种方式称为分解能力。这个能力实际上是要求我们提前考虑一个粗颗粒的服务环境如何能够分解为多个细颗粒的环境，然后响应地调整最初的服务功能。
