SOA，Service Oriented Architecture，顧名思義是面向服務的架構，整個系統要藉助服務的設計來完成建模，因此服務的設計是整個系統中很重要的一環。服務的設計牽涉到兩個重要的概念，一個是粒度，一個是耦合。
粒度表示的是一個服務的大小，它可以理解爲服務操作的範圍，粗粒度的服務，操作的內容廣而且雜；細粒度的服務，操作的內容細而且簡單。粗粒度的服務設計，可以減小服務之間的耦合性，但付出的代價就是增加服務的複雜性，服務具備了太多的功能，增加了設計的複雜性和維護的難度；細粒度的服務，可以讓服務的實現變得簡單，但這樣會增加服務的數量，服務過細過多，這樣必然有一些服務需要組合才能實現一定的功能，那樣就增加了服務之間的耦合度，只要其中一個服務發生了變動，勢必牽一髮而動全身。
耦合代表的是服務與服務之間的關係。SOA的初衷就是爲了降低系統各個部分之間的耦合性，使得服務可以重用。但很顯然，耦合性是受到服務粒度很大的影響，而且從某種程度上講，粒度的選擇就決定了系統內部的耦合性。
那麼應該以什麼爲準則來確定一個服務的粒度呢？遺憾的是，網上搜索了各種SOA的介紹和各個廠商的文檔，似乎找不到一個統一的標準，因爲服務粒度往往要根據需求來確定。SOA提倡服務要粗粒度，但這樣的說法太籠統，系統必然會有細粒度的服務存在，很多粗粒度的服務不過是一些細粒度服務的組合。所以我的看法是，粗中有細。
我的想法是，把服務分解爲三種類型，一種是基本服務，一種是組合服務，一種是合成服務。
- 基本服務。基本服務即是系統提供的最小粒度的服務，或者說是原子服務。這類服務考慮的是利用它們的可重用性，它們是組成一些較大粒度的服務的基礎。基本服務可以說是原有系統跟業務需求細分的中間結合點，它既是原有系統能夠提供的最細粒度的服務，同時也是要設計的系統最細粒度的服務。
- 合成服務。合成服務是基本服務簡單的組合，只是爲了把具有相同功能但操作不同的業務對象的基本服務組合到一起，形成一個對外提供相同功能的服務。它類似設計模式裏面的工廠模式，只要告訴服務接口傳進來的是哪一個業務對象，那麼服務就能自動識別應該調用哪一個基本服務。
- 組合服務。組合服務是系統裏面最複雜的部分，它不是基本服務的簡單堆積到一塊，它是最大粒度的服務，裏面各個基本服務的關係受到工作流程的控制。它是基本服務與工作流程的結合。
基於上面的理解，我們的服務設計遵循這樣的設計思路：先從功能模塊分離出基本服務，各個功能模塊可以看成是合成服務，由功能模塊分離出來的就是基本服務；然後在基本服務的基礎上設計組件和業務對象；設計完組件和業務對象之後再來設計組合服務。這樣不管組合服務需要多少，組合服務多複雜，都可以通過基本服務和工作流程進行各種形式組合起來。而且組合服務經常需要變動，這樣的設計能夠保證這些變動不會引起太大的改動。它們的組合關係可以用下面的圖來表示。
這樣的設計思路也體現了SOA的自頂向下的設計方法：功能模塊->服務->組件和業務對象。服務不是憑空想象出來的，它必須要滿足客戶的需求，而客戶需求的體現就是系統要提供的功能，所以功能模塊的設計是服務設計的前提。以我們團隊這次IBM大賽的方案爲例子，我們在理解大賽組委會給出的業務需求外，自己也設想了一些需求，對應這些需求，我們設計了系統的功能模塊。不同的業務角色有不同的業務需求，所以功能模塊對應不同的角色也就有所不同。下面的圖列舉的是財務人員所需要的功能模塊：
系統功能模塊是系統提供的各類服務的編排和合成。在設計完系統的功能模塊後，在這個基礎上把各個功能模塊的服務提取出來，一個功能模塊可能由一個服務組成，也可能由多個服務組成。
服務的基礎是組件，一些重要的組件能夠單獨封裝成服務。基礎服務其實就是一個業務組件，它是基於商務對象的原子操作。它是封裝好的組件，它只關心定義好的組件接口，和需要傳遞的對象，而不關心實現這個操作是如何用代碼來實現。業務組件包含兩個重要的含義，一個是“操作”，一個是“操作的對象”。組件的設計是基於面向對象的，可以說，它就是一個類，但它只能是一個抽象類，只有定義，沒有實現。
基礎服務跟合成服務、組合服務之間的關係可以用下面的圖來舉個例子：
訂單處理服務（Order Service）是各種基本服務的組合，基本服務包括產品類別服務（ProdClass Service）、產品庫存服務（ProdStorage Service）、客戶信息服務（Cust Service）、消息服務（Msg Service）等等。基本服務針對一個特定的業務操作對象，比如客戶信息服務處理的是客戶信息，它操作的對象就是客戶信息，操作就包括新增、修改、刪除、查找等等基本操作。訂單處理服務包括了各種基本服務，但它不是同時調用這些基本服務，而是必須按照一定的工作流程，比如先新增客戶信息，然後再查找產品類別、產品庫存，然後再發送消息，這些順序由工作流引擎來控制。
同步服務（Synchronize Service）是各種基本服務的合成，基本服務包括產品類別服務（ProdClass Service）、產品庫存服務（ProdStorage Service）、客戶信息服務（Cust Service）等等。相比訂單處理它就簡單不少，它只需要根據請求調用相應的服務完成操作就可以，沒有順序的要求。
雖然本文描述的只是一種業務場景下的服務粒度的選擇，但我想從我們團隊的設計經歷，可以總結出一種對服務粒度選擇的方法，那就是自頂向下，由粗到細，然後再從基礎到合成、組合。