細化架構設計
多檢視方法不僅僅是架構歸檔技術，更是指導我們進行架構設計的思維方法。將不同涉眾關心的技術堆砌到一起，每個涉眾都有可能看不懂了。另外，軟體架構設計必須圍繞「如何構建軟體」制定多方面的設計決策，可能涉及的概念有很多：邏輯層（layer）、物理層（tier）、子系統、模組、介面、程序、執行緒、訊息、協議，等等。基於之前介紹的5檢視的架構設計方法，是解決上述兩個問題的卓有成效的辦法。運用5檢視方法進行架構設計的細化。實際經驗表明，越是負責的系統，越是需要從多個方面進行架構設計，這樣才能把問題研究和表達清楚。而提供不同的軟體架構檢視也便於交流和傳遞設計思想。軟體架構是團隊開發的基礎，運用基於5檢視的架構設計方法可以比較明確地規定後期分頭開發所必須的公共性的設計約定，從而為分頭開發提供足夠的指導和限制。
概念性架構設計，確定了最為關鍵的設計要素和互動機制。在概念性架構設計的基礎上，運用更多具體的設計技術，設計出能夠為實際開發提供足夠多指導和限制的實際架構。軟體架構中包括了軟體系統如何組織等關鍵決策，模組的技術細節被區域性化到了小組內部。
關鍵需求是對軟體架構設計起關鍵作用的需求子集，包括功能需求、質量（屬性）需求、商業需求三類。領域模型是以物件導向方式對問題領域的模擬和抽象，領域模型被不斷精化之後成為最終軟體系統的問題領域層，它決定了軟體系統的功能範圍，並影響著軟體系統的可擴充套件性。概念性架構是對系統設計的最初構想，通過主要的設計元素及它們之間的關係來描述系統。
每個專案都是很有獨特的，因此開發人員必須努力保持微觀過程的非正式性和巨集觀過程的正式性之間的平衡。
邏輯架構設計著重考慮功能需求——系統應當向使用者提供什麼樣的服務。邏輯架構的關注點主要是行為或職責的劃分。軟體架構關心的是如何將系統分為不同部分以及各部分之間如何互動，因此架構師在將系統劃分為不同邏輯單元之後，必須考慮這些邏輯單元之間又是如何協作的。
機制是模式的例項，機制必須進一步細化才能成為特定模型中的協作，因此，機制是獨特上下文中重複出現的問題的特定解決方案。可以說，機制符合模式的定義。
概念完整性是產品質量的核心，具有良好架構的系統具備概念完整性。類很少單獨存在。因此，尤其當考慮到系統的動態性時，應重點靠靠某幾組物件如何協作以便使用通用機制來處理公共行為。開發架構的設計著重考慮開發期質量屬性，例如可擴充套件性、可重用性、可移植性、易理解性、易測試性等。開發架構的關注點是軟體開發環境中軟體模組的實際組織方式，具體涉及源程式檔案、配置檔案、源程式包、編譯（或許還有打包）後的目標檔案、第三方庫檔案等。開發架構和邏輯架構之間存在一定的對映關係。變化無處不在。好的架構設計必須把變化點錯落有致地封裝起來。分層架構模式為「把變化點封裝起來」提夠了手段。分層架構的最大優點是將整體問題區域性化，把可能的變化分別封裝在不同的層中，系統被規劃為乙個單向依賴的分層體系，利於修改、擴充套件、替換。框架封裝了設計元素之間的互動機制和協作流程，無論架構是自開發的還是第三方實現的，這些設計思想都是架構的一部分。框架是分割槽方法最常用的例子，可以更進一步地分離關注點——將應用相關和應用無關的部分分離——將不同變化進行分門別類地封裝。
系統=程式+資料+硬體。資料的規劃應該成為架構設計的重要組成部分。資料架構的關注點是持久化資料的組織。資料架構的設計需要完成持久化資料儲存方案設計和資料傳遞、資料複製、資料同步等策略。資料架構的設計可以有不同的方法：既可以從oo模型開始，也可以從經典的邏輯資料模型開始（但筆者認為，從經典的邏輯資料模型開始，比較符合問題分解的思路，但容易進行以資料為中心的設計思路，導致領域模型建設的失敗，所以，筆者還是建議從領域模型的建設入手，然後再考慮如何持久化資料的問題）。從oo模型到資料模型的對映，有著完整的規則體系。
執行架構的設計著重考慮執行期質量屬性，例如效能、可伸縮性、持續可用性等。執行架構關注程序、執行緒、物件等執行時概念，以及相關的併發、同步、通訊等問題。執行架構是在開發架構的基礎上，從巨集觀上規劃多條控制流的併發和同步。
物理架構的設計著重考慮「安裝和部署需求」。物理架構還和資料的分布相關。如果說，系統=程式+資料+硬體，那麼物理架構就是要定義「程式」如何對映（安裝、部署或燒寫等）到「硬體」，以及「資料」如何在「硬體」上儲存和傳遞。物理架構必須考慮「功能的分布」和「資料的分別」這兩方面。對分布式應用而言，物理架構常被稱作部署架構。
約束性需求往往能夠影響架構設計的方向，必須認真對待。約束性需求規定了開發軟體系統時必須遵守的限制條件，忽視它們可能導致架構設計的失敗。和功能性需求相比，約束並不強調行為，它既可能是設計開發時必須遵循的標準，也可能是硬體的限制，還可能時法律法規等社會因素的影響。
對於邏輯架構而言，有非常多的設計工作要做。識別架構的通用機制是非常重要的。架構設計應該盡量採取一致的機制來解決相似的問題。
實現並驗證軟體架構
架構設計是現代軟體開發中最為關鍵的一環，架構設計得是否合理將直接影響到軟體系統最終是否能夠成功。軟體架構中包含了關於如何構建軟體的一些最重要的設計決策。可以將原型法分為兩類：水平原型和垂直原型。水平原型在一定程度上實現使用者互動層的介面布局和介面流轉邏輯。垂直原型乙個形象隱喻是「垂直切片」，它往往是涉及到不同的層，將為數不多的功能真正的實現。根據所開發的原型是否被拋棄，我們又可以將原型法分為兩類：拋棄原型和演進原型。大多數用於需求啟發的水平拋棄原型只注重模擬待開發系統的介面布局和介面流轉情況，真正的業務邏輯都未實現。垂直丟擲性原型常用來進行技術驗證。垂直演進原型和迭代式軟體開發所暗示的「多次交付，增量交付」的思想完全一致。垂直演進原型方法強調逐步提供使用者所要求的功能。我們應當注重每個此次將提交的功能必須是可用的並且有或接近產品發布級的產品質量，而不是有些實踐者所認為的無需達到發布級質量。水平原型又稱為行為原型；拋棄原型又稱為探索原型；垂直原型又稱為結構原型。
驗證架構有兩種方法——原型法和框架法。對於專案型開發，常採用「原型法」。其實準確而言「垂直演進原型」：為了真實地驗證架構的表現，必須將選定的功能特性完整地實現。對於產品型開發，採用「框架法」有更多有點。所謂「架構驗證的框架法」就是將架構設計方案用框架的形式實現，並在此基礎上進行評估驗證。引入框架之後，整個「應用空間」的分割多了乙個維度——框架實現與具體應用無關的通用機制和通用元件，這利於支援產品型開發的生命週期長、應用版本多等特定。
歸納驗證架構的具體步驟：首先，必須將架構設計方案付諸實現，得到的架構原型可以是純粹的垂直演進原型，也可以是基於架構框架的原型。之後，分頭進行執行期和開發期質量屬性的測試或評審，分別得到執行期質量的測試結果和開發期質量的評審結果。最後，判斷架構設計是否呵護要求，如果不合格，應決定下一步需要對架構的哪些方面進行重現設計。主要的設計機制參與執行的、或有較高技術風險的、或最影響使用者滿意度的一些功能。一句話，這些功能要麼是使用者「最關心的」，要麼是架構師「最擔心的」。我們必須讓架構「跑」起來，從而對它進行真實的測試，測試的重點是質量屬性的測試。必須進行實實在在的驗證：讓實際測試結構告訴我們架構的執行期表現，讓開發人員告訴我們架構的開發期表現。
《軟體架構設計》學習筆記 摘錄（三）
成功的架構設計 好的架構應當具有如下品質 軟體架構師的工作成功要為整個軟體開發團隊的工作提供足夠的指導和限制，使他們能夠沿著正確的方向進行下去。軟體架構師開展架構設計工作，都是以 軟體需求規格說明書 為最主要的設計依據的，都是先勾畫出概念性架構，再結合具體技術平台制定實際架構。非功能需求來自何處？一...
《軟體架構設計》學習筆記 摘錄（三）
成功的架構設計 好的架構應當具有如下品質 軟體架構師的工作成功要為整個軟體開發團隊的工作提供足夠的指導和限制，使他們能夠沿著正確的方向進行下去。軟體架構師開展架構設計工作，都是以 軟體需求規格說明書 為最主要的設計依據的，都是先勾畫出概念性架構，再結合具體技術平台制定實際架構。非功能需求來自何處？一...
《軟體架構設計》學習筆記 摘錄（四）
需求分析 那些沒有經驗的問題解決者們，幾乎無一例外，都是去匆忙地尋找解決辦法，而不是先給要解決的問題下定義。什麼是軟體需求？什麼是需求捕獲 需求分析和系統分析？需求描述了系統必須滿足的情況或提供的能力，它就可以是直接來自客戶需要，也可以來自合同 標準 規範或其他有正規約束力的文件。需求的捕獲是獲取知...