這樣的設計思路也體現了SOA的自頂向下的設計方法：功能模塊->服務->組件和業務對象。服務不是憑空想象出來的，它必須要滿足客戶的需求，而客戶需求的體現就是系統要提供的功能，所以功能模塊的設計是服務設計的前提。以我們團隊這次IBM大賽的方案為例子，我們在理解大賽組委會給出的業務需求外，自己也設想了一些需求，對應這些需求，我們設計了系統的功能模塊。不同的業務角色有不同的業務需求，所以功能模塊對應不同的角色也就有所不同。下面的圖列舉的是財務人員所需要的功能模塊：
系統功能模塊是系統提供的各類服務的編排和合成。在設計完系統的功能模塊后，在這個基礎上把各個功能模塊的服務提取出來，一個功能模塊可能由一個服務組成，也可能由多個服務組成。
服務的基礎是組件，一些重要的組件能夠單獨封裝成服務�；A服務其實就是一個業務組件，它是基于商務對象的原子操作。它是封裝好的組件，它只關心定義好的組件接口，和需要傳遞的對象，而不關心實現這個操作是如何用代碼來實現。業務組件包含兩個重要的含義，一個是“操作”，一個是“操作的對象”。組件的設計是基于面向對象的，可以說，它就是一個類，但它只能是一個抽象類，只有定義，沒有實現。
基礎服務跟合成服務、組合服務之間的關系可以用下面的圖來舉個例子：
訂單處理服務（Order Service）是各種基本服務的組合，基本服務包括產品類別服務（ProdClass Service）、產品庫存服務（ProdStorage Service）、客戶信息服務（Cust Service）、消息服務（Msg Service）等等�；痉⻊蔗槍σ粋�特定的業務操作對象，比如客戶信息服務處理的是客戶信息，它操作的對象就是客戶信息，操作就包括新增、修改、刪除、查找等等基本操作。訂單處理服務包括了各種基本服務，但它不是同時調用這些基本服務，而是必須按照一定的工作流程，比如先新增客戶信息，然后再查找產品類別、產品庫存，然后再發送消息，這些順序由工作流引擎來控制。
同步服務（Synchronize Service）是各種基本服務的合成，基本服務包括產品類別服務（ProdClass Service）、產品庫存服務（ProdStorage Service）、客戶信息服務（Cust Service）等等。相比訂單處理它就簡單不少，它只需要根據請求調用相應的服務完成操作就可以，沒有順序的要求。
雖然本文描述的只是一種業務場景下的服務粒度的選擇，但我想從我們團隊的設計經歷，可以總結出一種對服務粒度選擇的方法，那就是自頂向下，由粗到細，然后再從基礎到合成、組合。
