x 重用性
所謂重用性，就是指服務能夠套用於不同上下文的能力。重用可以說是SOA的核心思維，通過重用獲得降低開發維護成本，縮短套用交付周期，提升質量等種種好處。
與任何基於分解的範例相一致，顆粒度的大小直接影響到服務的可重用性。一個簡單的經驗法則就是細粒度的服務更容易被重用。換句話說，就是顆粒度越粗，服務越少被重用或者越難以被重用。因為隨著顆粒度增加，越來越多的業務規則和上下文信息被嵌入到業務邏輯中，服務逐漸變得具有特定的業務意義。要使用它，我們必須首先了解它到底封裝了哪些規則，否則我們無法確信這個服務正是我們所需要的。這並不意味著我們就不要構建粗粒度的服務，事實上粗粒度的服務往往還停留在”business-grained”層面，它讓業務用戶和IT人員可以直接對話，對業務有直接的意義，應該暴露出來。同時，如果我們僅僅機械地考慮重用性，將導致大量顆粒度很小的功能單元，這將對系統整體性能和容量帶來嚴重的影響。就拿大家常用來描繪SOA的樂高玩具為喻，一個最小尺寸的1x1的樂高積木，帶有一個標準的凸起接口，通過它幾乎可以與任何其它樂高積木拼裝出任意可以想想的物體，其廣泛的重用性是不言而喻的。但是當你真正嘗試用這種粒度的積木完成一個複雜物體拼裝的時候，你可能會感嘆：“Oh, My God! It’s mission impossible!”，因為，為此付出的時間和成本的代價幾乎是不可接受的。因此，我們在一心希望構建美好的重用世界之前，需要先掂量清楚服務顆粒度的選擇。
在這裡，我借用關於演講的一個有名的“迷你裙定律”來嘗試表達服務顆粒度的選擇上的權衡之道。“mini-skirt theory”告訴我們，一個出色的演講應該“short enough to keep people interested, but long enough to cover the important part”。套用在服務顆粒度的選擇上，一個設計良好的服務應該“fine-grained enough to be reusable, but coarse-grained enough to make business sense”。
x 靈活性
所謂靈活性，就是能夠容易地因情形做出改變的能力。SOA的目標之一就是讓IT變得更靈活，能夠更快地適應持續變化的業務環境。因此，靈活性作為設計良好的服務的重要考量，理所當然地也是選擇服務粒度的重要標準之一。眾所周知，細粒度的服務可以更容易地組裝，為交付新的業務功能或改變業務流程提供了更多的靈活性。但是，僅僅考慮靈活性將導致大量的細粒度的服務，帶來昂貴的開發成本，並使得維護變得困難。因此，在考慮業務流程靈活性的同時，考慮後台服務的良好組織、效率和開發維護成本，對於識別和設計粒度適中的服務是至關重要的。
我們知道，服務識別方法之一就是top-down的一級級流程分解，直到不能或者不需要進一步分解為止，其中識別出來的的業務活動就是候選的業務服務。因此，一個有效的經驗法則就是區別對待不同的業務流程，因為並不是每一個業務流程都需要相同的靈活性。如何確定哪些流程需要更多的靈活性，哪些流程不需要，可以參考SAP就企業業務流程的一個觀點。SAP將流程劃分為核心流程（core process）和支撐流程(context process)。其中，支撐流程是指那些不可或缺的，但又不影響企業差異化的流程，如財會管理流程等，它們關注的是如何提升生產效率，降低生產成本。因此這些流程在分解過程中，一旦識別出自治的（事務一致、上下文獨立的）、粗粒度的服務就可以結束，因為它們相對穩定。而核心流程是指企業獨特的，差異化的，代表企業競爭力的業務流程，如行銷銷售流程等。它們需要比支撐流程更細粒度地分解，以獲得最大的靈活性，因為它們是時刻變化的。
x 性能
靈活性和效率往往是成對出現的，性能因素自然也是限制服務粒度不能太大或者太小的約束之一。Dan Foody曾在他的weblog里建議Webservice的每一個operation執行應該在5ms到5s之間完成，小於5ms或者 大於5s就意味著服務粒度要么太小，要么太大。我在這裡倒不想評價這個量化的指標有多大指導意義，而是藉此希望引起大家的思考，並不是服務粒度越小或者越大，系統性能就會一定越好。
一個服務本身的複雜度以及業務到服務映射的複雜度（即實現一個業務活動所需的服務調用次數）是影響SOA性能的兩個主要方面。服務顆粒度越大，意味著包含的功能越多，業務邏輯越複雜，網路延遲就會增加，對客戶端回響變慢。而服務顆粒度越小，也就意味著包含的功能越簡單，雖然單個服務執行效率很高，但從業務意義上，完成一項業務任務所需的服務調用次數越多，來回請求回響次數增加。一般來說，服務都是遠程調用的，這種來回請求回響的次數增加意味著顯著的性能開銷。因此，為了保證服務的性能可控，一方面需要限制服務包含的功能範圍和複雜度，也就是說服務粒度不能太粗；另一方面需要限制服務調用的次數和複雜度，也就是說服務粒度不能太細。我想這才是前面提到的5ms和5s背後真正的原因。很顯然，二者的著眼點是背離的，為了符合性能的需求，需要在二者之間折中妥協。
除以上幾點之外，還存在其它可能影響服務顆粒度決策的因素，比如服務類別和使用範圍等等。如果服務使用的範圍有限，如僅僅在Intra-Application範疇，則可以選擇相對較細粒度的服務接口，為服務請求者提供更多的靈活性；隨著範圍擴大，服務大小也應隨之擴大，如Multi-Enterprise的範疇，則要求服務儘可能提供粗粒度的、較穩定的接口，保證服務請求者以一致的方式使用系統中所暴露出的服務。最後，需要記住的一點是，服務的顆粒度在其生命周期內不是一成不變的，它是隨著業務的調整變化，以及服務的疊代發展過程，不斷演化精煉、甚至重構的。
