軟件架構---架構分解篇

4.1、架構分解

http://www.ibm.com/developerworks/cn/rational/1312_wanggb_arch/index.html

架構分解是架構設計過程中非常關鍵的一步。除了識別架構元素，對大規模的軟件系統，

分解還是解決非功能需求的重要手段。

比如解決可伸縮性、可用性、可管理性等問題，在架構的多個層面進行了分解：
在應用層面，按照功能或 SOA 服務進行分解，將系統垂直拆分爲多個應用池（應用池中的服務是無狀態的）。

每個應用池中有多個應用（水平拆分），可以獨立靈活地進行伸縮。
在數據層面，對數據進行垂直拆分（分庫）和水平拆分（數據分片 DB Sharding）；

將分佈式事務拆分成多個本地事務獨自提交，避免分佈式事務。

1、爲了正確的進行分解，需要遵循一些分解原則：
低耦合、高內聚：“分解的主要難點在於怎麼分。分解策略之一是按容易求解的方式來分，

之二是在弱耦合處下手，切斷聯繫”。

在弱耦合處下手，切斷聯繫。太精闢了！高內聚、低耦合也是軟件設計的基本原則，

軟件設計中的很多設計原則其實都可以認爲它的派生或具體化，如單一職責原則、依賴倒置原則、模塊化封裝原則，

這些原則在架構分解中也是適用的。
層次性：分解通常是先業務後技術，循序漸進，先邏輯後物理，從上到下逐級進行分解展開：

系統－>子系統－>模塊－>組件->類。
正交原則：和物理學中的正交分解類似，架構分解出的架構元素應是相互獨立的，在職責上沒有重疊。
抽象原則：架構元素識別，在較大程度上是架構師抽象思維的結果，

架構師應該具備在抽象概念層面進行架構構思和架構分解的能力。
穩定性原則：將穩定部分和易變部分分解爲不同的架構元素，穩定部分不應依賴易變部分。

根據穩定性原則，將通用部分和專用部分分解爲不同的元素；

將動態部分和靜態部分分解爲不同的元素；將機制和策略分離爲不同的元素；

將應用和服務分離。
複用性原則：就是對知識的重用.重用類似系統已有的架構設計、設計經驗、成熟的架構模式

或參考模型、設計模式、領域模型、架構思想等，

因爲它們已經在不同的層次上分解識別出了許多架構元素，或者指出了一些分解方向，

對我們的架構分解具有借鑑和指導作用。

例如 IBM SOA 解決方案參考模型對 SOA 服務化具有重要的指導意義，

我們可以參照它對系統進行初步的架構分解。

2、架構分解的過程模型：
對複雜的系統，特別是前人沒有做過的新系統，通常難以一下子設計出合適的架構。在架構設計的初期，

通常都要經歷一個不斷探索的階段。
在架構設計過程中，架構分解是必不可少的的關鍵步驟。如何進行架構分解？從哪裏入手開始進行分解？

我們需要有一個架構分解的過程模型來指導分解過程，啓發和探索架構分解的維度和線索，提高架構分解的效率。
架構分解過程模型如下圖 所示，是一個迭代的模型。

通過這個迭代的分解，從無到有、從粗到細、從模糊到清晰，一步步精（細）化、豐富架構。

迭代的過程也是一個否定之否定的過程，隨着分解的逐步推進或系統的架構演化，

後面的分解除了會識別出新的架構元素，也可能會對先前識別出的架構作出調整。

依次在 4 個域中進行架構分解，基本順序是先業務後技術，通過多維度多層次的分解將關注點分離。
A 業務域分解：先從業務域進行分解，狹義的業務域具有商業的概念，從這個概念來看，有的系統沒有業務域，

但如果寬泛一點來看，業務域就是問題域（問題空間），問題域總是存在的。
首先是從系統需求入手，尋找業務域中的分解維度，將架構從業務域層面進行大尺度（大粒度）的分解。在業務域中進行分解，

通常採用的分解維度是根據業務主題，將系統分解爲多個子系統，每個子系統聚焦於一個獨立的業務主題，子系統間具有清晰的邊界。

例如對某零售系統，我們可以根據業務主題維度進行架構分解，初步劃分出：主數據子系統、採購子系統、貨品管理子系統、會員子系統、

銷售子系統、營運子系統、訂單中心子系統等。

對業務域分解不應只侷限於基於業務主題的分解，根據具體情況，還可能有其他的分解維度。

一個通用的發現分解維度的方法是試着從領域模型和需求分析文檔中尋找名詞和形容詞，將文檔中的核心概念（名詞和形容詞）

作爲分解的候選分解維度或分解線索。
在業務域的分解中，我們要和業務（行業）專家密切交流，多研究業務架構、適當考慮企業戰略，

這樣可在一定程度上保證架構分解的合理性。
B 業務功能域分解：通過對業務流程和用例進行分析，根據功能職責，進行垂直和水平分解，識別出業務功能或業務服務，

將它們歸類到子系統中相應模塊中去。
對業務域功能域分解，一個通用的方法是試着通過動詞來將子系統拆分爲多個服務；另一個是根據資源類型（名詞）來將系統拆分爲服務，

每個服務負責實現對應資源上的一組操作。例如根據資源類型（會員、商品等），

對電商系統，可分解識別出會員查詢服務和會員管理模塊、商品服務等。
這兩步的架構分解都是純業務上的，不涉及技術，但要這兩步分解出的架構元素要映射到技術域中去實現，

或用來幫助架構師推導出技術域的對應架構元素。
C 技術域分解：是從技術角度對系統和模塊進行分解。在該階段，通常會選取關鍵的需求（包括功能需求和非功能性需求）和

已分解出的模塊或子系統，結合當前的 IT 技術（技術框架、架構模式、參考架構、中間件、業務平臺）和

架構思想、架構經驗、開發人員的技能以及系統的上下文環境等，進一步進行架構分解。
例如很多系統採用 MVC、多層架構模式、SOA、事件驅動架構等技術或思想進行技術域中的架構分解。

對電商交易子系統的訂單流程，

考慮到要需要靈活支撐多種交易流程和解耦流程層與業務邏輯層的需要，

按照 IBM SOA 的參考架構可以分拆出流程層、服務層等，在流程層中採用流程引擎技術。

在技術域分解中，對功能需求，橫切（分層）豎割是一種常用的分解手法。

對非功能需求，可將性能、伸縮性、可用性等作爲維度對系統進行分解，

在非功能需求分解戰術中將專門說明這些維度的分解技術（稱爲戰術）。
在業務域和業務功能域中分解出來的架構元素，考慮到技術實現，在映射到技術域時，

可能要對架構元素進行修改或作一些微調，

業務域和業務功能域中分解出的架構元素通常會進一步分解爲技術域中的多個架構元素。

例如在業務功能域分解出的會員查詢服務模塊，

在技術域中分解時，考慮到有多個不同類型的調用方會使用該服務，並且這些調用方需要的查詢接口差異較大，

調用頻率等也不一樣，

那我們可能會對每個調用方拆分出獨立的查詢接口模塊，這樣也避免了胖接口，相關的 DAO 類也是在技術域中新產生的。
在從模塊分解到類的過程中（假設有些模塊要分解到類級別），需要進行靜態和動態的分析以便識別出類元素。

首先是根據業務域需求，建立領域模型，識別出領域（概念）類，再將領域類映射到技術域中的設計類（實體類），

也就是領域類可幫助我們識別推導出部分設計類。再基於具體用例，進行魯棒分析和序列圖設計，考慮技術上的實現和採用的技術架構，

例如採用一些技術框架和類庫或工具類，如 ibatis 框架，就會識別出另一些設計類（邊界類、控制類）或引入一些新的設計類，

這些引入的類可能直接來自框架或類庫，或是繼承框架中的類（成爲框架類的子類）。

通常設計過程不會就此結束，考慮到開發維護和設計質量等因素，

我們會運用一些設計原則（如高內聚低耦合、單一職責、信息專家等）、設計模式、重構模式等對設計進行進一步的優化，

這時又會產生識別出一些設計類，通常在這一步會對我們的設計進行一些修改和調整，

例如採用工廠方法設計模式，會引入工廠方法類，

我們的序列圖就要修改。這樣我們最終完成了一個完整的設計。

因爲要考慮技術域，所以對整個分析設計來說，它是源於業務但要高於業務。
在技術域的分解中，對公共的技術需求應全盤考慮，抽象出底層的公共技術基礎設施，例如定時任務在許多子系統中都存在，

此時可能會規劃一個定時任務框架和定時任務執行系統。也可能會採用一些成熟的框架和中間件技術，如消息中間件、ESB 等。
技術域的分解通常是比較複雜的，這一方面來源於問題域的本質複雜性，

特別是各種非功能性需求的複雜性，需要架構師掌握應對這些需求的常見模式。

另一方面也是由於 IT 新技術的日新月異，要求架構師對技術敏感，與時俱進。
要注意的是，當在技術域分解中碰到困難時，可以再回到業務域中去尋找答案和線索。例如爲了解決某計費系統中的性能和可伸縮性問題，

可在業務域中尋找名詞和形容詞，發現可以根據付費類型（預付費和後付費）將系統初步分拆爲預付費系統和後付費系統。對網絡通訊系統，

可以根據請求消息中的某些屬性對消息處理系統進行拆分或根據客戶端類型等進行拆分。
D 涉衆域分解：全面考慮各類涉衆在架構層面的關鍵需求，特別是非功能需求，例如性能需求、可伸縮性需求等，進一步對系統進行分解。
涉衆域分解包括了前面說的業務域分解、業務功能域分解、技術域分解，通常涉衆域分解和它們有部分是重疊的，例如在技術域和涉衆域中

都有性能方面的架構分解。涉衆域分解保證我們的分解是完備的，沒有遺漏。
在涉衆域的分解過程中，很可能會產生新的子系統，例如考慮用戶的性能方面的需求，

可能會分解出分佈式數據緩存子系統（也可能在技術域分解中就已經考慮到了）。
涉衆域分解的一個可能的維度是根據涉衆類型，基於他們的關注點來進行架構分解，

試着爲某類涉衆劃分出對應的子系統或模塊（架構元素），

例如考慮到前臺涉衆和後臺涉衆的用戶類型、關注點差別較大等因素，可能會將系統劃分爲前臺系統和後臺系統兩大類。

對第三方涉衆（外部系統），考慮到接入認證授權、安全性和互操作性，可能會分解出網關子系統。
爲何首先從業務域開始分解，其實很好理解，我們開發一個系統肯定是爲了解決業務問題，是爲業務服務的，

不可能脫離業務去設計一個空洞的無目標的系統和架構。

4.2、架構分解的粒度

多維度多層次分解到什麼粒度才停止？這個沒有統一的標準，通常要能進行並行開發，能指導後續的詳細設計。

需要根據具體的產品或項目來定，有的到模塊級別就行，對關鍵的部分，可以到類級別。

4.3、架構分解的時機

架構分解的時機通常就是架構改造演化的時機。當架構出現腐化和臭味，已經難以滿足關鍵涉衆的關鍵需求，

例如用戶的響應速度越來越慢已經接近臨界值，並且根據預見，響應速度還有可能繼續較低；開發人員越來越難以維護，

這個時候可以考慮進行架構演化，對架構進行改造。當然如果能提前預見系統的問題，經過慎重評估後，在問題發生之前，

提前一段時間進行架構演化也是可以的。
要注意的問題是不要過度分解，過早分解，這樣做除了增加成本，還可能帶來風險。例如很多系統在建設初期，

考慮到規模較小和快速上線，通常都是一個整體的系統，不會進行大的架構分解，以後隨着需求和規模的逐漸增加，

會逐步進行架構改造和架構分解。