SOA
Service-Oriented Architecture 面向服務的架構，將應用程序的不同功能單元(服務)進行拆分，并通過服務之間定義良好的接口和契約聯(lián)系起來。
“服務”并不僅僅是一個按照標準暴露出 API 的對象，也不是面向對象編程的“放大版”。確實，如同面向對象給過程式編程帶來了另一層次的抽象和思維，面向服務也給面向對象編程帶來了另一層次的抽象和思維。
確實，面向服務的運動根本不是關于技術的！它是一個面向業(yè)務的運動，里頭的抽象正是關于企業(yè)如何看待自身組織中變化不息的方方面面，以及如何用松耦合的方式將它們組織起來，從而造就出平緩而可預測的成本變動。這就是說我們要重新思考我們看待 IT 能力的方式，而不是簡單地以同樣的方式暴露出同樣的資源，而僅僅是采用了新的接口或者中間件。
一般我們開發(fā)程序都避免不了自頂向下和自底向上的兩種開發(fā)方式（或者兩種都有）
從業(yè)務過程或者業(yè)務模型開始著手，然后將之遞歸分解成子過程或者子模型，直到達到某些條件，再繼續(xù)分解就會違反這些條件位置。或者架構師從系統(tǒng)開始著手，從已有的 API 和訪問點中暴露出服務的接口，以這些接口為基礎創(chuàng)建出新的服務和契約，然后將它們組合起來，直到滿足業(yè)務過程中的需求
適當?shù)拿嫦蚍辗治龊驮O計方式應該從以下五個關鍵方面分別考慮粒度和原子性的問題：服務的可復用性、效率、事務性、可消費性（Consumability）和可見性。一開始從復用的角度看應該成為復合服務的，實際上可能出于事務性的考慮而應該成為原子服務。類似地，出于可見性和安全審查的考慮似乎應該成為細粒度服務的，可能因為效率的關系而應該改用粗粒度。這份服務粒度表格僅僅是一位高效的企業(yè)架構師腰帶上掛著的又一把工具。
所以決定粒度大小的并不是一成不變的，一個粗粒度的服務在特定的環(huán)境下非常適合，并不意味在其他環(huán)境也是最好的。服務是跟著他們的應用程序一起演變的。
