如何恰到好处地分解服务力量

SOA专家Dave Linthicum说，当你观察那些建立SOA的企业的时候，似乎有一些明显的趋势：他们或者分解的服务数量太多，或者分解的数量不够。SOA的核心观点是把你的架构分解为信息和雨信息有关的服务。因此，SOA中的S就是服务。然而，许多人正在把服务分解成太多的部分，或者分解的远远不够。Linthicum说，也许我能提供帮助。

如果服务分解看起来在SOA中是新的，实际上却不是。事实是，作为一种设计技术，分解自从结构化程序设计的时候就出现了。当时，我们是做流程分解以便在我们把这个设计提供给程序员之前更好地定义系统。

实际上，服务分解是把比较长的、粗颗粒的服务分解为比较小的、细颗粒的服务。根据架构的对象，可以创建和应用许多分解规则。这个规则对于架构有巨大的影响。这些影响包括：

灵活性

性能

开发时间

再利用

复杂性

因此，你必须知道什么时候停止分解服务，不管这些服务是否来自现有的系统或者从头建立的系统。但是，怎样做呢?下面是Linthicum提出的服务分解的一些简单技巧：

1.一定要建立有关服务分解的架构规则，考虑到上述各个项目。一定要把规则写下来并且与其他设计师共享。例如，有人需要确定粗颗粒的或者细颗粒的服务应该是什么样的才能提供需要的性能以及再利用。

2.作为拇指定律，一个服务应该仅提供一个单项功能，一般不超过500行的3GL代码(如C++)。

3.例如，验证客户信贷等级(指向一个单独的功能)与处理客户信贷申请(主要是许多功能结合在一起的)。再说一次，这只是拇指定律。

可是却又不对采集或是转载而来的内容稍作修改 一定要让开发人员参加服务分解流程。因此，当他们过度分解服务或者分解服务不足的时候，他们应该能够让你知道可用的服务是什么和不可用的是什么。