一線架構師實踐指南

第1章 緒論
1.1 一線架構師︰6個經典困惑
1.2 本書的4個核心主張
1.2.1 方法體系是大趨勢
1.2.2 質疑驅動的架構設計
1.2.3 多階段還是多視圖？
1.2.4 內置最佳實踐
1.3 ADMEMS方法體系︰3個階段，1個貫穿環節
1.3.1 Pre—architecture階段︰ADMEMS矩陣方法
1.3.2 Conceptual Architecture階段︰重大需求塑造做概念架構
1.3.3 Refined Architecture階段︰落地的5視圖方法
1.3.4 持續關注非功能需求︰“目標.場景.決策”表方法
1.4 如何運用本書解決“6大困惑”
第Ⅰ部分 Pre-Architecture階段.
第2章 Pre—architecture的故事
2.1 “不就是個MIS嗎”
2.1.1 故事︰外籍人員管理系統
2.1.2 探究︰哪些因素構成了架構設計的約束性需求
2.2.1 故事︰嵌入式0S的剪裁
2.2.2 探究︰又是約束
2.3 “都是C++的錯，換C重寫”
2.3.1 故事︰放棄C++，用C重寫計費系統
2.3.2 探究︰相互矛盾的質量屬性
2.4 展望“Pre—architecture階段篇”
第3章 Pre.architecture總論
3.1 什麼是Pre.architecture
3.2 實際意義
3.2.1 需求理解的大局觀
3.2.2 降低架構失敗風險
3.2.3 盡早開始架構設計
3.2.4 明確架構設計的“驅動力”
3.3 業界現狀
3.3.1 “唯經驗論”
3.3.2 “目標不變論”
3.3.3 需求分類法的現狀
3.3.4 需求決定架構的原理亟待歸納
3.4 實踐要領
3.4.1 不同需求影響架構的不同原理，才是架構設計思維的基礎
3.4.2 二維需求觀與ADMEMS矩陣方法
3.4.3 關鍵需求決定架構，其余需求驗證架構
3.4.4 Pre.architecture階段的4個步驟
第4章 需求結構化與分析約束影響
4.1 為什麼必須進行需求結構化
4.2 用ADMEMS矩陣方法進行需求結構化
4.2.1 範圍︰超越《軟件需求規格說明書》
4.2.2 工具︰ADMEMS矩陣
4.3 為什麼必須分析約束影響
4.4 ADMEMS方法的“約束分類理論”
4.5 Big Picture︰架構師應該這樣理解約束
4.6 用ADMEMS矩陣方法輔助約束分析
4.7 大型82C網站案例︰需求結構化與分析約束影響
4.7.1 需求結構化
4.7.2 分析約束影響（推導法則應用）
4.7.3 分析約束影響（查漏法則應用）
4.8 貫穿案例
4.8.1 PASS系統背景介紹
4.8.2 需求結構化
4.8.3 分析約束影響
第5章 確定關鍵質量與關鍵功能
5.1 為什麼要確定架構的關鍵質量目標
5.2 確定關鍵質量的5大原則
5.2.1 整體思路
5.2.2 分類合適+必要擴充
5.2.3 考慮多方涉眾
5.2.4 檢查性思維
5.2.5 識別矛盾+劃定優先級
5.2.6 嚴格程度符合領域與規模特點
5.3 為什麼不是“全部功能作為驅動因素”
5.4 確定關鍵功能的4條規則
5.5 大型82C網站案例︰確定關鍵質量與關鍵功能
5.6 貫穿案例
第Ⅱ部分 Conceptual Architecture階段
第6章 概念架構的故事
第7章 Conceptual Architecture總論
第8章 初步設計
第9章 高層分割
第10章 考慮非功能需求
第Ⅲ部分 Refined Architecture階段
第11章 細化架構的故事
第12章 Refined Architecture總論
第13章 邏輯架構
第14章 物理架構、運行架構、開發架構
第15章 數據架構的難點︰數據分布
第Ⅳ部分 專題︰非功能目標的方法論
第16章 故事︰困擾己久的非功能問題
第17章 總論︰非功能目標的設計環節
第18章 方法︰“目標－場景－決策”表
索引
編輯手記
設計手記

方法之于個人，乃至軟件業，都是至關重要的。對架構新手，方法是陌生之地的抬路明燈，避免架構設計者不知所措（這很常見）；對架構老手，方法是使經驗得以充分發揮的思維框架，指導桀枸設計者擺脫“害怕下一個頊目”的心理和“思維毫無章法”的狀態；對軟件業而言，方法是整個產業“上升一個層次”的“內功”，沒有“內功”為基礎，單靠“外力”促進軟件產業升級是不現實的。

本書致力于為一線架構師，以及軟件企業提供務實有效的架構設計方法指導。

為什麼這麼多架構師總是抱怨需求呢？因為不少架構師不懂需求，而更多架構師缺乏需求的大局觀。為此，可以看看本書【第1部分Pre-architecture階段】的“ADMEMS矩陣方法”、以及“約束性需求的四種類型”等內容。

設計穩定的架構，首要的一點是什麼呢？是概念架構必須穩定。為此，可以看看本書【第2部分Conceptual Architecture階段】是如何展開闡述“重大需求塑造概念桀構”的。

如何更合理地將系統切分為子系統呢？笞案是遵循職責分離原則、通用專用分離原則、技能分離原則、工作量均衡原則等設計思想的要求。本書【第3部分Refined Architecture階段】講解了分層的細化、分區的引入、機制的提取等實踐技巧。

回顧過去，我在金融、航空、多媒體、電信、中間件平台等領域的職業經歷中，幸運地遇到了很多良師益友，他們的智慧和無私使我受益匪淺；近幾年，在軟件企業一線開展架構培訓與咨詢工作時，認真務實的客戶讓我進一步開闊了視野，了解了軟件業一線的現狀……這些，都是本書所講述的架構設計方法伐孬形成和發展的原動力。所以，由哀感謝︰所有幫助和支持過我的前輩、專家、客戶！

可通過shanghaiwenyu＠163．cOm與我聯系，歡迎探討、批評、指正。

資深咨詢顧問 溫昱
2009年8月于上海