粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了变动，势必牵一发而动全身。
耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。
那么应该以什么为准则来确定一个服务的粒度呢？遗憾的是，网上搜索了各种SOA的介绍和各个厂商的文档，似乎找不到一个统一的标准，因为服务粒度往往要根据需求来确定。SOA提倡服务要粗粒度，但这样的说法太笼统，系统必然会有细粒度的服务存在，很多粗粒度的服务不过是一些细粒度服务的组合。所以我的看法是，粗中有细。
我的想法是，把服务分解为三种类型，一种是基本服务，一种是组合服务，一种是合成服务。
基本服务。基本服务即是系统提供的最小粒度的服务，或者说是原子服务。这类服务考虑的是利用它们的可重用性，它们是组成一些较大粒度的服务的基础。基本服务可以说是原有系统跟业务需求细分的中间结合点，它既是原有系统能够提供的最细粒度的服务，同时也是要设计的系统最细粒度的服务。
合成服务。合成服务是基本服务简单的组合，只是为了把具有相同功能但操作不同的业务对象的基本服务组合到一起，形成一个对外提供相同功能的服务。它类似设计模式里面的工厂模式，只要告诉服务接口传进来的是哪一个业务对象，那么服务就能自动识别应该调用哪一个基本服务。
组合服务。组合服务是系统里面最复杂的部分，它不是基本服务的简单堆积到一块，它是最大粒度的服务，里面各个基本服务的关系受到工作流程的控制。它是基本服务与工作流程的结合。
基于上面的理解，我们的服务设计遵循这样的设计思路：先从功能模块分离出基本服务，各个功能模块可以看成是合成服务，由功能模块分离出来的就是基本服务；然后在基本服务的基础上设计组件和业务对象；设计完组件和业务对象之后再来设计组合服务。这样不管组合服务需要多少，组合服务多复杂，都可以通过基本服务和工作流程进行各种形式组合起来。而且组合服务经常需要变动，这样的设计能够保证这些变动不会引起太大的改动。它们的组合关系可以用下面的图来表示。
这样的设计思路也体现了SOA的自顶向下的设计方法：功能模块->服务->组件和业务对象。服务不是凭空想象出来的，它必须要满足客户的需求，而客户需求的体现就是系统要提供的功能，所以功能模块的设计是服务设计的前提。以我们团队这次IBM大赛的方案为例子，我们在理解大赛组委会给出的业务需求外，自己也设想了一些需求，对应这些需求，我们设计了系统的功能模块。不同的业务角色有不同的业务需求，所以功能模块对应不同的角色也就有所不同。下面的图列举的是财务人员所需要的功能模块：
文章来源于领测软件测试网 https://www.ltesting.net/