緒論
從本質上，架構設計是需求驅動的，而不是模型驅動的。但當很清楚需求卻依然設計不出架構時，就說明「需求驅動的架構設計」的總結還「缺點什麼」。架構設計是一門藝術，不可能把「一桶需求」倒進某台神奇的機器，然後等著架構設計自己被「加工生成」完畢，因此「需求驅動的架構設計」的總結給架構師的啟發不夠。那缺點兒什麼呢？答案是「人的因素」、「架構師的因素」。
質疑意識，是架構師最寶貴的意識之一。通過「質疑」引入更多的「質量屬性」，以及「特殊功能場景」來驅動後續架構設計工作的開展。
架構設計方法的階段：
階段1：把握需求特點，確定架構確定力
階段2：根據重大需求，確定概念架構
階段3：細化架構設計，關注不同檢視
先做後做——叫做階段，齊頭並進——叫做檢視。任何好的方法（不限於軟體領域），都必須以時間軸來組織，因為這樣才最利於指導實踐。
3個階段，1個貫穿
pre-architecture階段（pa階段）：最大誤區：架構師是技術人員不必懂需求。
conceptual architecture 階段（ca階段）：最大誤區：概念架構=理想設計。
refined architecture 階段（ra階段）：最大誤區：架構=模組+介面
對非功能目標的考慮貫穿整個架構設計階段。
子系統劃分的4大原則：
l 職責分離原則
l 通用專用分離原則
l 技能分離原則
l 工作量均衡原則
pre-architecture階段
作為架構師，首先要面對的風險就是需求。既要關注功能需求，又要平衡相互矛盾的質量屬性需求，還不能遺漏各方的約束性需求。架構師不僅要考慮支援功能、滿足質量要求，還要重視各種約束性需求。
相互矛盾的質量屬性：高效能和靈活擴充套件這兩個質量屬性之間存在矛盾關係，效能和安全性，與其他許多質量屬性都是矛盾的。
在架構設計之初，就全盤考慮架構設計要重點支援的關鍵質量目標。在第一時間就判斷這些「關鍵質量」之間有沒有衝突關係，並制定權衡取捨策略。
架構師不必是需求捕獲專家，也不必是編寫《軟體需求規格說明書》的專家；但他一定應在需求分類、需求折中和需求變更的研究方面是專家。
架構設計對系統成敗非常關鍵。功能需求、質量屬性及約束共同決定了架構，對這3類需求的把握是否到位、設計決策是否對路，是架構設計成敗的關鍵所在。
四步法：
1、 需求結構化
2、 分析約束影響
3、 確定關鍵質量
4、 確定關鍵功能
pre-architecture就是架構設計的最前期階段，其工作目標包括：理解需求、建立需求大局觀、確定架構設計方向等。該階段雖然是鋪墊性質的階段，但對架構實際而言意義重大。
重大需求塑造概念架構。如果對需求的理解缺乏大局觀，那將如何識別重大需求、特色需求、高風險需求？pre-architecture階段能夠幫助架構師建立理解需求的大局觀。任何需求都可定位於業務級需求、使用者級需求、開發級需求這3個需求層次的某一層，同時也必屬於功能、質量、約束這3類需求的某一類。
對需求理解不透、遺漏需求往往是架構設計失敗的重要原因。
盡早開始架構設計
l 讓架構師參與需求分析工作，讓架構師相對自由地「全程」參與需求分析工作。
l 不能被動地等待完善的《軟體需求規格說明書》出現的那一刻才開始架構設計。滿足下列3個條件就可以盡早開始架構設計工作：
1、 有了明確的業務需求
2、 了解全面的使用者需求
3、 有了典型的行為需求
明確架構設計的「驅動力」
l 分析業務需求和約束背後的衍生需求
l 發現遺漏需求
l 確定關鍵功能
l 確定關鍵質量
l 權衡質量屬性之間的矛盾關係
架構設計的目標必然隨領域不同、規模不同、條件不同而變化。為重用、簡單、可擴充套件都加了「最」（而不是權衡折中），不符合架構設計的實現、更何況「靈活」和「簡單」之間常常存在矛盾。
任何一項功能都是由一條特定的「職責協作鏈」完成的。作為完整的軟體系統，它在支援每乙個具體功能時，都必然涉及軟體不同「部分」之間的相互配合。質量是完善架構設計的驅動力，不考慮質量的系統是無法走出實驗室的。至於約束，則有不同的具體方式影響著架構設計。把多而雜的架構影響因素梳理清楚、建立全面有序的理解。分別針對約束、質量、功能這3類需求開展相應工作。分析約束影響，識別隱含需求；確定關鍵質量，明確關鍵質量之間的優先順序；確定關鍵功能，便於更有針對性地分配有限的架構設計時間。
需求結構化
有經驗的架構師懂得運用需求的結構。他們能夠將複雜的需求集合梳理得井井有條，為進一步分析不同需求之間的聯絡（作為權衡折中的依據）、識別遺漏的重要需求打下堅實基礎。pre-architecture 階段要求進行需求結構化。全面理解需求的各個層次、各個方面，更為分析需求之間關係、識別遺漏需求、發現延伸需求奠定基礎。絕不能認為《軟體需求規格說明書》就是需求的全部。首先，需求文件常常不夠全面，所有有經驗的架構師都重視需求文件，但不應該「唯需求文件是瞻」。其次，需求變更經常發生，「依賴且僅依賴需求文件」不夠聰明，使架構設計工作非常被動。所以，架構師要通過需求結構化真正全面地「鳥瞰」需求大局，就必須超越《軟體需求規格說明書》。還有乙個重大的意義在於，只有擺脫對《軟體需求規格說明書》提交時間、文件質量、內容變更的「呆板依賴」，才有可能盡早開始架構設計。
需求是分層次的。業務級需求：包含客戶或出資者要達到的業務目標、預期投資、工期要求，以及要符合哪些標準、對哪些遺留系統進行整合等約束條件。使用者級需求：使用者使用系統來輔助完成哪些工作？對質量有何要求？使用者群及所處的使用環境方面有何特殊要求？開發級需求：開發人員需要實現什麼？開發期間、維護期間有何質量考慮？開發團隊的哪些情況會反過來影響架構？需求的三個層次，是站在「不同層次的涉眾提出需求所站的立場不同」的角度，將需求劃分為三種型別。其次，需求還必須從不同方面進行考慮。實踐一再表明，忽視質量屬性和約束性需求，常常導致架構設計最終失敗。於是，從「需求定義了直接目標還是間接限制」的角度，把需求劃分為3種型別，這就是需求的3個方面：
功能需求：更多體現各級直接目標要求。
質量屬性：執行期質量+開發期質量。
約束需求：業務環境因素+使用環境因素+構建環境因素+技術環境因素。
一句話，需求是有結構的。而且，需求的結構絕對不是「list」，而應該是「二維陣列」。結構化是控制複雜性的好辦法。進行需求結構化之後，複雜性得到了控制。
為什麼必須分析約束影響
風險有乙個惱人的特點：一旦你忘記了它，它就會找上門來製造麻煩。對於架構設計而言，來自方方面面的約束性需求中潛藏了大量風險因素。pre-architecture階段明確要求必須分析約束影響。分析約束影響的要義：盡早識別風險。業務環境、使用環境、構建環境應分別考慮客戶、使用者、開發方這3類涉眾，而技術環境則和3類涉眾都有關。
第一，來自客戶或出資方的約束性需求。架構師必須充分考慮客戶對上線時間的要求、預算限制，以及整合需要等非功能需求。
第二，來自使用者的約束性需求。軟體提供給何階層使用者？使用者的年齡段？使用偏好？使用者是否遍及多個國家？使用期間的環境有電磁干擾、車船移動等因素嗎？
第三，來自開發人員和公升級維護人員的約束性需求。如果開發團隊的技術水平有限、磨合程度不高、分布在不同城市，會有何影響？開發管理方面、源**保密方面，是否須要顧及？
第四，也不能遺忘，業界當前技術環境本身也是約束性需求。技術平台、中介軟體、程式語言等的流行度、認同度、有缺點等。技術發展的趨勢如何？
架構是應當直接或間接地了解和掌握上述需求和約束，並深刻理解它們對架構的影響，只有這樣才能設計出合適的軟體架構。
約束是架構設計的上下文。沒有全域性觀念就不可能成為架構師，「約束是架構設計要解決的問題的上下文」是乙個犀利的理解，揭示了「軟體需求=功能需求+質量屬性+約束」背後更深層次的規律。從本質上講，分析約束影響就是分析各個需求項之間的關係，並發現被遺漏的需求。
確定關鍵質量
如何確定關鍵質量呢？遵守和運用5 大原則：
n 分類合適+必要擴充。
n 考慮多方涉眾。
n 檢查性思維。
n 識別矛盾+劃定優先順序。
n 嚴格程度符合領域與規模特點。
質量的分類方式是基礎，架構師對質量毫無研究絕對不行。任何時候，只要關鍵屬性多於乙個，都要考慮它們之間是否有矛盾關係，在第一時間做出權衡取捨，確定不同的優先順序。
持續可用性包括了可靠性。若是分布式系統，安全性差會隨時造成系統癱瘓，持續可用性將大受影響，所以持續可用性也包括安全性高的隱含要求。可維護性和可管理性也深刻影響著持續可用性。效能=速度+吞吐量+持續高速性。效率=cpu、記憶體、硬碟和網路的利用率。
為什麼會遺漏重要的質量屬性呢？因為架構師沒有全面考慮多方涉眾的利益。使用者在使用軟體系統的過程中，其關心的質量屬性可能包括易用性、效能、可伸縮性、持續可用性、魯棒性等。架構師也應為開發人員而設計。軟體的可擴充套件性、可重用性、可移植性、易理解性、易測試性等也類似，它們都深刻影響著開發人員的工作，使開發更順暢，抑或更艱難。
檢查性思維這條原則頗為簡單。這是一種意識，意識到「在架構設計之初」像「過一遍checklist」一樣，看看每一項質量屬性是否確實算不上「關鍵質量」，從而防止遺漏關鍵需求。
架構師應確定關鍵質量的優先順序，並在《架構文件》中明確記錄此要求。
質量嚴格程度受到系統所處領域及系統規模的影響。首先，不同領域對軟體系統的質量要求不同。其次，規模不同，對同一領域的軟體而言，產品的要求常常也比專案高，平台的要求常常比產品高。
確定關鍵功能的4條規則
1. 核心功能
2. 必做功能
3. 高風險功能
4. 獨特功能
識別「核心功能」的標誌是業務層的介面要放映這些功能。
關鍵功能子集」的確定並不存在「標準答案」。只要較好地覆蓋組成架構的不同職責模組，並體現職責模組之間協作關係的特點，那麼「關鍵功能子集」的價值也就體現了。
一線架構師實踐指南（一）
緒論 從本質上，架構設計是需求驅動的，而不是模型驅動的。但當很清楚需求卻依然設計不出架構時，就說明 需求驅動的架構設計 的總結還 缺點什麼 架構設計是一門藝術，不可能把 一桶需求 倒進某台神奇的機器，然後等著架構設計自己被 加工生成 完畢，因此 需求驅動的架構設計 的總結給架構師的啟發不夠。那缺點兒...
一線架構師實踐指南（一）
這本書大致可以分為三部分，第一部分pre architecture階段，第二部分conceptual architecture階段，第三部分refined architrcture階段。因為課程需求之前讀過了第三部分，最近有時間回過頭將整本書閱讀一遍，收穫頗多。書中明確指出唯經驗論和目標不變論是不可...
在讀《一線架構師實踐指南》
和溫昱先生相識已經有些年頭了，我們見面的時候，經常是他慢慢地說，我靜靜地聽。有編輯說他仙風道骨，我有時也會有這種感覺，聆聽他的話語，很長見識。從網上看到一些人對 一線架構師實踐指南 的一些非議，我個人感覺不是很舒服。中國不缺罵街的貨，但即便是罵街，也應該朝著韓寒或者魯迅的旗幟去努力，別總是說一些不著...