这样的设计思路也体现了SOA的自顶向下的设计方法：功能模块->服务->组件和业务对象。服务不是凭空想象出来的，它必须要满足客户的需求，而客户需求的体现就是系统要提供的功能，所以功能模块的设计是服务设计的前提。以我们团队这次IBM大赛的方案为例子，我们在理解大赛组委会给出的业务需求外，自己也设想了一些需求，对应这些需求，我们设计了系统的功能模块。不同的业务角色有不同的业务需求，所以功能模块对应不同的角色也就有所不同。下面的图列举的是财务人员所需要的功能模块：
系统功能模块是系统提供的各类服务的编排和合成。在设计完系统的功能模块后，在这个基础上把各个功能模块的服务提取出来，一个功能模块可能由一个服务组成，也可能由多个服务组成。
服务的基础是组件，一些重要的组件能够单独封装成服务。基础服务其实就是一个业务组件，它是基于商务对象的原子操作。它是封装好的组件，它只关心定义好的组件接口，和需要传递的对象，而不关心实现这个操作是如何用代码来实现。业务组件包含两个重要的含义，一个是“操作”，一个是“操作的对象”。组件的设计是基于面向对象的，可以说，它就是一个类，但它只能是一个抽象类，只有定义，没有实现。
基础服务跟合成服务、组合服务之间的关系可以用下面的图来举个例子：
订单处理服务（Order Service）是各种基本服务的组合，基本服务包括产品类别服务（ProdClass Service）、产品库存服务（ProdStorage Service）、客户信息服务（Cust Service）、消息服务（Msg Service）等等。基本服务针对一个特定的业务操作对象，比如客户信息服务处理的是客户信息，它操作的对象就是客户信息，操作就包括新增、修改、删除、查找等等基本操作。订单处理服务包括了各种基本服务，但它不是同时调用这些基本服务，而是必须按照一定的工作流程，比如先新增客户信息，然后再查找产品类别、产品库存，然后再发送消息，这些顺序由工作流引擎来控制。
同步服务（Synchronize Service）是各种基本服务的合成，基本服务包括产品类别服务（ProdClass Service）、产品库存服务（ProdStorage Service）、客户信息服务（Cust Service）等等。相比订单处理它就简单不少，它只需要根据请求调用相应的服务完成操作就可以，没有顺序的要求。
虽然本文描述的只是一种业务场景下的服务粒度的选择，但我想从我们团队的设计经历，可以总结出一种对服务粒度选择的方法，那就是自顶向下，由粗到细，然后再从基础到合成、组合。
