當下，SOA這個詞已經深入人心，幾乎沒有人不說自己設計的應用是遵從SOA的。
很多人對SOA的理解就是分層、模塊化、面向對象。。。這種理解對不對后面再說。先看一些問題：
我今天看了一個開發團隊的開發工程包結構，部分類的命名及組織產生了如下印象：
- 每個usecase是一根根煙囪
- 煙囪與煙囪之間連模型都沒有共享。其實業務模型是有設計的，主要是實現模型沒有保持業務模型的結構特征，全部成了“值對象”，開發人員天天把這些值對象叫做領域對象。
- 有三層，是Struts幫忙定義的，三層分別根據usecase分包
這也是我們宣稱的SOA系統！！！！連最基本的模型設計、模塊設計、分層設計都沒做好，難怪年年重構、年年完成不可能完成的任務！！！我確信這種重構、這種不可能完成的任務還會年年持續下去！！！
究竟什么是符合SOA風格的系統？先看看SOA宗師IBM的一篇文章：
http://www.ibm.com/developerworks/cn/architecture/ar-soastyle/
我來總結一下。
SOA能達到什么目的：
1.實現業務與IT的一致性；
2. 創建更靈活的反應更敏捷的IT基礎設施；
3. 簡化集成實現；
SOA要怎么做？
- 從應用程序到流程和服務。消除應用程序，將軟件系統創建為一組由業務流程進行協調的交互服務。每個服務實現企業上下文中定義的特定業務目標或功能，業務流程表示必須實現的業務解決方案。這個講的比較抽象，我的解讀就是服務表示一個最細粒度的業務目標或功能，由業務流程來編排這些服務，實現更大粒度的業務目標或功能，業務流程也是服務。注意，這里隱式的定義了服務的概念，服務是自治的，可替換的，可被多個流程編排的，不耦合流程上下文的，是直接面向業務目標或功能的，不是一個公共函數庫，服務不是封裝了數據和方法的類。
- SOA的服務基于業務資源（對象）定義，不支持操作者的執行上下文，而是支持業務資源（對象）。這里的業務資源是指業務實體。業務實體也是來自業務的。所以，SOA能保證IT與業務的一致性。
別再說你的應用程序或煙囪遵循SOA的架構風格！