架構的典型組成部分

一、程序組織：

1.系統架構首先要以概括的形式對有關系統做一個綜述。假設沒有這樣的綜述，要想將成千的局部圖片拼成一幅完整的圖畫是相當傷腦筋的。

2.在架構中，應該發現對那些以前考慮過的終於組織結構的替代方案的記敘。找到之所以選用終於的組織結構。而不用其它替代方案的理由。

3.架構應該定義程序的主要構造塊。

依據程序規模不同。各個構造塊可能是單個類，也可能是有很多類組成的一個子系統。

4.應該明白定義各個構造塊的責任。

每一個構造塊應該負責某一個區域的事情。而且對其它構造塊負責的區域知道得越少越好。

通過使各個構造塊對其它構造塊了解達到最小，你能將設計的信息局限於各個構造塊之內。

5.應該明白定義每一個構造塊的通信規則。

對於每一個構造塊。架構應該描寫敘述他能直接使用那些構造塊，能間接使用那些構造塊。不能使用哪些構造塊。

二、基本的類

架構應該具體定義所用的基本的類。

它應該指出每個基本的類的責任。以及該類怎樣與其它類交互。

它應該包括對類的繼承體系、狀態轉換、對象持久化等的描寫敘述。架構無須具體說明系統中的每個類，瞄準80/20原則。對那些構成系統80%的行為的20%類進行具體說明。

三、數據設計

1.架構應該描寫敘述所用的主要文件和數據表的設計。

它應該描寫敘述以前考慮過的其它方案，並說明做出選擇的理由。

2.數據通常僅僅應該由一個子系統或一個類直接訪問。

3.架構應該具體定義所用數據庫的最高層組織結構和內容。架構應該解釋為什麽單個數據庫比多個數據庫要好（反之亦然），解釋為什麽不用平坦文件而要用數據庫，指出與其它訪問同一數據的程序的可能交互方式，說明會創建哪些數據視圖等等。

四、業務規則

假設架構依賴於特定的業務規則。那麽它就應該具體描寫敘述這些規則。並描寫敘述這些規則對系統設計的影響。

五、用戶界面設計

1.用戶界面經常在需求階段進行具體說明。假設沒有。就應該在軟件架構中進行具體說明。

2.架構應該模塊化，以便在替換為新用戶界面時不影響業務規則和程序的輸出部分。

六、資源管理

架構應該描寫敘述一份管理稀缺資源的計劃。稀缺資源包含：數據庫連接、線程、句柄等。

七、安全性

架構應該描寫敘述實現設計層面和代碼層面的安全性的方法。

在定制編碼規範的時候應該把安全性牢記在心，包含處理緩沖區的方法、處理非受信數據的規則、加密、錯誤消息的仔細程度、保護內存中的秘密數據。以及其它事項。

八、性能

1.假設須要關註性能，就應該在需求中具體定義性能目標。

2.架構應該提供預計的數據，並解釋為什麽架構師相信能達到性能目標。假設某些部分存在達不到性能目標的風險，那麽架構也應該指出來。假設為了滿足性能目標，須要在某些部分使用特定的算法或數據類型。架構也應該說清楚。

架構中也能夠抱括各個類或各個對象的空間和時間預算。

九、可伸縮性

可伸縮性是指系統增長以滿足未來需求的能力。

架構應該描寫敘述系統怎樣應對用戶數量、server數量、網絡節點數量、數據庫記錄數、數據庫記錄的長度、交易量等的增長。

十、互用性

假設估計這個系統會與其它軟件或硬件共享數據或資源，架構應該描寫敘述怎樣完畢這一任務。

十一、國際化/本地化

對交互系統，國際化問題值得在架構中關註。大多數交互式系統包括幾十上百條提示、狀態顯示、幫助信息、錯誤信息、等等。應該估算這些字符串所用的資源。

假設這是一個在商業中使用的程序。架構應該表現出已經考慮過典型的字符串問題和字符集問題，包括所用的字符串類型。假設無須更改代碼就能維護這些字符串，怎樣將這些字符串翻譯為還有一種語言而又盡量不影響代碼和用戶界面。

十二、輸入輸出

架構應該具體定義讀取策略是先做、後作還是即時做。並且應該描寫敘述在那一層測I/O錯誤：在字段、記錄、流，或者文件的層次。

十三、錯誤處理

錯誤處理已被證實為現代計算機科學中最棘手的問題之中的一個。錯誤處理牽連到整個系統，因此最好在架構層次上對待他。

1.錯誤處理是進行糾正還是只進行檢測？假設是糾正，程序能夠嘗試從錯誤中恢復過來。

2.錯誤檢測是主動的還是被動的？系統能夠主動滴預測錯誤。

3.程序怎樣傳播錯誤？程序一旦檢測到錯誤。它能夠立馬丟棄引發該錯誤的數據；也能夠把這個錯誤當成一個錯誤，並進入錯誤處理狀態。或者能夠等到全部處理完畢，再通知用戶說在某個地方發現了錯誤。

4.錯誤消息的處理有什麽約定？假設架構沒有具體定義一個一致的處理策略，那用戶界面看起來很糟。

5.怎樣處理異常？架構應該規定代碼何時可以拋出異常，在什麽地方捕獲異常。怎樣記錄這些異常，以及怎樣在文檔中描寫敘述異常，等等。

6.在程序中，在什麽層次上處理錯誤？

7.每一個類在驗證其輸入數據的有效性方面須要負何種責任？

8.是希望執行環境中內建的錯誤處理機制。還是想建立自己的一套機制？

十四、容錯性

架構還應該具體定義所期望的容錯種類。容錯是增強系統可靠性的一組技術，包含檢測錯誤；假設可能的話從錯誤中恢復；假設不能從錯誤中恢復，則包容其不利影響。

十五、架構的可行性

設計師多半會關註系統的各種能力。比如是否達到性能目標，可以在有限的資源下運轉，實現環境是否有足夠的支持。

架構應該論證系統的技術可能性。假設在不論什麽一個方面不可行都會導致項目無法實施，那麽架構應該說明“這些問題是怎樣經過研究的”——通過驗證概念的原型、研究、或其它手段。必須在全面開展構建之前解決掉這些風險。

十六、過度project

健壯性是指“系統在檢測到錯誤後繼續執行”的能力。

通常架構具體描寫敘述的系統會比需求描寫敘述的系統更健壯。理由之中的一個是，假設組成系統的各個部分都僅僅在最低限度上滿足健壯性要求，那麽系統總體上是達不到所要求的健壯程度的。在軟件中。鏈條的強度不是取決於最薄弱的一環，而是等於全部薄弱環節的乘積。架構應該清楚地指出程序猿應該“為了慎重起見寧可進行過度project”。還是應該做出最簡單的能工作的東西。

具體定義一種過度project的方法尤其重要，由於很多程序猿會處於專業自豪感。對自己編寫的類做過度project。

通過在架構中明白地設立期望目標。就能避免出現“某些類異常健壯。而其它類勉強夠健壯”的現象。

十七、關於“買”還是“造”的決策

採購IP進行整合還是自己進行設計，都應該給出具體的分析。

十八、關於復用的決策

關於開發計劃提倡使用已存在的軟件、測試用例、數據歌會或其它原料。

架構應該說明：怎樣對復用的軟件進行加工，使之符合其它架構目標。

十九、變更策略

要面對開發過程中產品的變化，軟件架構師所遇到的挑戰是，讓架構靈活，可以適應核能出現的變化。

架構應當清楚地描寫敘述處理變更的策略。架構應該列出已經考慮過的有可能會有所增強的功能，並說明“最有肯能增強的功能相同也是最easy實現的”。假設變更非常可能出現輸入輸出格式、用戶交互的風格、需求的處理等方面。那麽架構就應該說明：這些變更已經被預料到了，而且不論什麽單一的變更都僅僅會影響少數幾個類。

二十、架構的整體質量

1、架構的目標應該清楚地表述。

2、架構應該描寫敘述全部主要決策的動機。

3、優秀的軟件架構非常大程度上是與機器和編程無關的。

4、架構應該踏在對系統”欠描寫敘述“和”過度描寫敘述“之間的那條分界線上。

5、架構應該明白地指出有風險的區域。他應該解釋為什麽這些區域是有風險的，並說明已經採取了哪些步驟以使風險最小化。

6、架構應該包括多個視角。

7、不應該擔憂架構的不論什麽部分。

它不應該不論什麽對你而言非常難理解的東西。

軟件架構————架構核對表