面向服務的分析和設計 SOAD

1、soad總體指導原則

- 經過良好構思的服務應該給業務帶來靈活性和敏捷性，它們通過松耦合、封裝和資訊隱藏等機制使服務的重新配置和復用更加容易

- 設計良好的服務之間的依賴被最小化而且被顯式宣告，最小依賴原則不僅僅適用於企業應用

- 服務抽象是內聚、完整和一致的。

- 服務是無狀態的，但可以減弱該假設以切合特定的問題域和場景

- 對服務的命名要做到能使其沒有較深技術知識的領域專家理解

- 在某個soa應用中，所有的服務都要遵循一致的設計哲學和互動模式，並且支撐應用的體系結構風格要鮮明以便於識別

- 服務開發者和服務使用者在具有領域知識外，僅需基本的程式設計技能；只有少數專業人員才需要專門的中介軟體知識。

2、soad過程框架

（1）服務識別

目的是定義系統功能，並把系統功能合理地組織成服務。

從業務域出發，對業務域進行分解和分析是服務識別的主要途徑；由於自頂向下和自底向上識別服務難免不夠全面，此時可以利用「目標-服務」對應建模方法（goal-service modeling)，以專案目標為基準，檢驗已識別服務的完備性。

進行服務識別時要掌握服務粒度原則和命名規範原則

服務粒度原則：基本原則是粗粒度(coarse-grained)，可用facade模式

包括：a. 領域分析：業務驅動的，自頂向下的服務識別活動。從業務角度，領域是一

組業務功能域的集合。業務用例通常是業務服務的極佳候選

b. 現存系統分析：自底向上，分析現存遺留系統以識別服務的活動。現存系統

作為實現部分業務過程功能的低成本解決方案，其相關api、事務、模組經過分析後

提公升為服務。有時，遺留系統需要構件化以支援服務功能。

c. 「目標-服務」建模：服務識別的目的是發現和整個組織業務相匹配的服務集

，「目標-服務」建模活動的目的是測試領域分解和現存系統分析識別的服務的完整

性，並適當地補充業務需要而未識別的服務。

（2）服務編目和聚集

該活動在服務識別完成後進行。把服務進行分類編目有利於服務的使用，比如業務服務和技術服務顯然有不同的功能和目的。通過服務聚集可以把細粒度的服務組合成更大粒度的服務，從而可以克服由於過多的細粒度服務存在而引起的效能、可伸縮性以及管理等問題。

（3）服務和構件規範

該步驟包括子系統分析、構件規範和服務規範活動。

a. 子系統分析：把在領域分解階段定義的業務用例求精為支援特定業務過程的系統用例，並識別子系統介面、業務構件、技術構件以及相互之間的依賴和流程關係。

b. 構件流程規範：該活動定義實現服務的構件細節，包括定義構件的資料、規則、服務、可配置的profile以及可變更項。

c. 服務規範：該活動詳細定義服務的功能、非功能屬性以及服務包含的具體操作。對復合服務還有定義其包含的服務的編排細節。

d. 服務流程規範

（4）服務實現：包括服務到構件的分配和服務實現決策。

a. 服務分配：服務分配活動把服務分配給各個子系統，這些子系統包含能實現服務功能的構件。這樣服務不僅可以向上回溯到對應的業務目標，而且也可以向下定位到實現服務的構件。

b. 服務實現決策：決定哪些服務用遺留系統模組實現，那些服務從零開始實現。其他還有整合、轉換、訂閱、部分外包等實現方法。影響服務實現決策的因素除了業務功能方面的考慮外，服務的安全、管理等非功能屬性也是重要的決策因素。