軟件架構設計 : 程序員向架構師轉型必備, 2/e

溫昱資深諮詢顧問，軟件架構專家。
軟件架構思想的傳播者和積極推動者，中國軟件技術大會傑出貢獻專家。
十五年系統規劃、架構設計和研發管理經驗，在金融、航空、多媒體、電信、中間件平台等領域負責和參與多個大型系統的規劃、設計、開發與管理。

第1章 從程序員到架構師 
1 1.1 軟件業人才結構 1 
1.1.1 金字塔型，還是橄欖型？ 1 
1.1.2 從程序員向架構師轉型 2 
1.2 本書價值 3 
1.2.1 閱讀路徑1：架構設計入門 3 
1.2.2 閱讀路徑2：領會大系統架構設計 4 
1.2.3 閱讀路徑3：從需求到架構的全過程 5 
1.2.4 閱讀路徑4：結合工作，解決實際問題 6 

第1部分 基本概念篇 
第2章 解析軟件架構概念 10 
2.1 軟件架構概念的分類 10 
2.1.1 組成派 11 
2.1.2 決策派 11 
2.1.3 軟件架構概念大觀 12 
2.2 概念思想的解析 13 
2.2.1 軟件架構關註分割與交互 13 
2.2.2 軟件架構是一系列有層次的決策 14 
2.2.3 系統、子系統、框架都可以有架構 17 
2.3 實際應用（1）——團隊對架構看法不一怎麽辦 18 
2.3.1 結合手上的實際工作來理解架構的含義 18 
2.3.2 這樣理解“架構”對嗎 19 
2.3.3 工作中找答案：先看部分設計 19 
2.3.4 工作中找答案：反觀架構概念的體現 22 

第3章 理解架構設計視圖 24 
3.1 軟件架構為誰而設計 24 
3.1.1 為用戶而設計 25 
3.1.2 為客戶而設計 26 
3.1.3 為開發人員而設計 26 
3.1.4 為管理人員而設計 26 
3.1.5 總結 27 
3.2 理解架構設計視圖 28 
3.2.1 架構視圖 28 
3.2.2 一個直觀的例子 28 
3.2.3 多組涉眾，多個視圖 29 
3.3 運用“邏輯視圖+物理視圖”設計架構 30 
3.3.1 邏輯架構 31 
3.3.2 物理架構 32 
3.3.3 從“邏輯架構+物理架構”到設計實現 32 
3.4 實際應用（2）——開發人員如何快速成長 33 
3.4.1 開發人員應該多嘗試設計 33 
3.4.2 實驗項目：案例背景、訓練目標 34 
3.4.3 邏輯架構設計（迭代1） 35 
3.4.4 物理架構設計（迭代1） 35 
3.4.5 邏輯架構設計（迭代2） 36 
3.4.6 物理架構設計（迭代2） 37 

第2部分 實踐過程篇 
第4章 架構設計過程 40 
4.1 架構設計的實踐脈絡 41 
4.1.1 洞察節奏：3個原則 41 
4.1.2 掌握過程：6個步驟 43 
4.2 架構設計的速查手冊 45 
4.2.1 需求分析 45 
4.2.2 領域建模 46 
4.2.3 確定關鍵需求 47 
4.2.4 概念架構設計 49 
4.2.5 細化架構設計 50 
4.2.6 架構驗證 51 

第5章 需求分析 53 
5.1 需求開發（上）——願景分析 53 
5.1.1 從概念化階段說起 54 
5.1.2 願景 54 
5.1.3 上下文圖 56 
5.1.4 願景分析實踐要領 60 
5.2 需求開發（下）——需求分析 60 
5.2.1 需求捕獲vs.需求分析vs.系統分析 61 
5.2.2 需求捕獲及成果 63 
5.2.3 需求分析及成果 64 
5.2.4 系統分析及成果 65 
5.3 掌握的需求全不全 65 
5.3.1 二維需求觀與ADMEMS矩陣 65 
5.3.2 功能 66 
5.3.3 質量 68 
5.3.4 約束 71 
5.4 從需求向設計轉化的“密碼” 72 
5.4.1 “理性設計”還是“拍腦袋” 72 
5.4.2 功能：職責協作鏈 73 
5.4.3 質量：完善驅動力 74 
5.4.4 約束：設計並不自由 74 
5.5 實際應用（3）——PM Suite貫穿案例之需求分析 75 
5.5.1 PM Suite案例背景介紹 76 
5.5.2 第1步：明確系統目標 77 
5.5.3 第2步：範圍 + Feature + 上下文圖 77 
5.5.4 第3步：畫用例圖 82 
5.5.5 第4步：寫用例規約 85 
5.5.6 插曲：需求啟發與需求驗證 86 
5.5.7 插曲：非功能需求 88 
5.5.8 《需求規格》與基於ADMEMS矩陣的需求評審 88 

第6章 用例與需求 89 
6.1 用例技術族 89 
6.1.1 用例圖 90 
6.1.2 用例簡述、用戶故事 90 
6.1.3 用例規約 91 
6.1.4 用例實現、魯棒圖 92 
6.1.5 4種技術的關系 93 
6.2 用例技術族的應用場景 94 
6.2.1 用例與需求分析 94 
6.2.2 用例與需求文檔 95 
6.2.3 用例與需求變更 97 
6.3 實際應用（4）——用例建模夠不夠？流程建模要不要 99 
6.3.1 軟件事業部的故事 99 
6.3.2 小型方法：需求分析的三套實踐論（上） 
99 6.3.3 中型方法：需求分析的三套實踐論（中） 100 
6.3.4 大型方法：需求分析的三套實踐論（下） 101 
6.3.5 PM Suite應用一幕 102 

第7章 領域建模 105 
7.1 什麽是領域模型 106 
7.1.1 領域模型“是什麽” 106 
7.1.2 領域模型“什麽樣” 106 
7.1.3 領域模型“為什麽” 107 
7.2 需求人員視角——促進用戶溝通、解決分析癱瘓 108 
7.2.1 領域建模與需求分析的關系 108 
7.2.2 溝通不足 109 7.2.3 分析癱瘓 110 
7.2.4 案例：多步領域建模，熟悉陌生領域 111 
7.3 開發人員視角——破解“領域知識不足”死結 113 
7.3.1 領域模型作為“理解領域的手段” 113 
7.3.2 案例：從詞匯表到領域模型 113 
7.4 實際應用（5）——功能決定如何建模，模型決定功能擴展 115 
7.4.1 案例：模型決定功能擴展 116 
7.4.2 實踐：功能決定如何建模 118 
7.4.3 PM Suite領域建模實錄（1）——類圖 122 
7.4.4 PM Suite領域建模實錄（2）——狀態圖 125 
7.4.5 PM Suite領域建模實錄（3）——可擴展性 126 

第8章 確定關鍵需求 129 
8.1 眾說紛紜——什麽決定了架構 129 
8.1.1 用例驅動論 130 
8.1.2 質量決定論 131 
8.1.3 經驗決定論 132 
8.2 真知灼見——關鍵需求決定架構 132 
8.2.1 “目標錯誤”比“遺漏需求”更糟糕 132 
8.2.2 關鍵需求決定架構，其餘需求驗證架構 132 
8.3 付諸行動——如何確定關鍵需求 133 
8.3.1 確定關鍵質量 133 
8.3.2 確定關鍵功能 135 
8.4 實際應用（6）——小系統與大系統的架構分水嶺 137 
8.4.1 架構師的“拿來主義”困惑 137 
8.4.2 場景1：小型PMIS（項目型ISV背景） 138 
8.4.3 場景2：大型PM Suite（產品型ISV背景） 139 
8.4.4 場景3：多個自主產品組成的方案（例如IBM） 140 
8.4.5 “拿來主義”雖好，但要合適才行 141 

第9章 概念架構設計 143 
9.1 概念架構是什麽 144 
9.1.1 概念架構是直指目標的設計思想、重大選擇 144 
9.1.2 案例1：汽車電子AUTOSAR——跨平臺復用 145 
9.1.3 案例2：騰訊QQvideo架構——高性能 149 
9.1.4 案例3：微軟MFC架構——簡化開發 150 
9.1.5 總結 151 
9.2 概念架構設計概述 151 
9.2.1 “關鍵需求”進，“概念架構”出 151 
9.2.2 概念架構≠理想化架構 152 
9.2.3 概念架構≠細化架構 152 
9.3 左手功能——概念架構設計（上） 153 
9.3.1 什麽樣的鴻溝，架什麽樣的橋 153 
9.3.2 魯棒圖“是什麽” 153 
9.3.3 魯棒圖“畫什麽” 154 
9.3.4 魯棒圖“怎麽畫” 156 
9.4 右手質量——概念架構設計（下） 159 
9.4.1 再談什麽樣的鴻溝，架什麽樣的橋 159 
9.4.2 場景思維 159 
9.4.3 場景思維的工具 160 
9.4.4 目標—場景—決策表應用舉例 162 
9.5 概念架構設計實踐要領 163 
9.5.1 要領1：功能需求與質量需求並重 163 
9.5.2 要領2：概念架構設計的1個決定、4個選擇 163 
9.5.3 要領3：備選設計 165 
9.6 實際應用（7）——PM Suite貫穿案例之概念架構設計 165 
9.6.1 第1步：通過初步設計，探索架構風格和高層分割 165 
9.6.2 第2步：選擇架構風格，劃分頂級子系統 169 
9.6.3 第3步：開發技術、集成技術與二次開發技術的選型 171 
9.6.4 第4步：評審3個備選架構，敲定概念架構方案 172 

第10章 細化架構設計 174 
10.1 從2視圖方法到5視圖方法 175 
10.1.1 回顧：2視圖方法 175 
10.1.2 進階：5視圖方法 175 
10.2 程序員向架構師轉型的關鍵突破——學會系統思考 176 
10.2.1 系統思考之“從需求到設計” 177 
10.2.2 系統思考之“5個設計視圖” 179 
10.3 5視圖方法實踐——5個視圖、15個設計任務 181 
10.3.1 邏輯架構＝模塊劃分＋接口定義＋領域模型 181 
10.3.2 開發架構＝技術選型＋文件劃分＋編譯關系 184 
10.3.3 物理架構＝硬件分佈＋軟件部署＋方案優化 185 
10.3.4 運行架構＝技術選型＋控制流劃分＋同步關系 187 
10.3.5 數據架構＝技術選型＋存儲格式＋數據分佈 188 
10.4 實際應用（8）——PM Suite貫穿案例之細化架構設計 189 
10.4.1 PM Suite接下來的設計任務 189 
10.4.2 客戶端設計的相關說明 191 
10.4.3 細化領域模型時應註意的兩點 192 

第11章 架構驗證 194 
11.1 原型技術 194 
11.1.1 水平原型vs.垂直原型，拋棄原型vs.演進原型 195 
11.1.2 水平拋棄原型 196 
11.1.3 水平演進原型 197 
11.1.4 垂直拋棄原型 197 
11.1.5 垂直演進原型 197 
11.2 架構驗證 198 
11.2.1 原型法 198 
11.2.2 框架法 199 
11.2.3 測試運行期質量，評審開發期質量 199 

第3部分 模塊劃分專題 
第12章 粗粒度“功能模塊”劃分 202 
12.1 功能樹 203 
12.1.1 什麽是功能樹 203 
12.1.2 功能分解≠結構分解 203 
12.2 借助功能樹，劃分粗粒度“功能模塊” 204 
12.2.1 核心原理：從“功能組”到“功能模塊” 205 
12.2.2 第1步：獲得功能樹 207 
12.2.3 第2步：評審功能樹 211 
12.2.4 第3步：粗粒度“功能模塊”劃分 
212 12.3 實際應用（9）——對比MailProxy案例的4種模塊劃分設計 213 
12.3.1 設計 213 
12.3.2 設計的優點、缺點 213 
12.4 實際應用（10）——做總體，要提交啥樣的“子系統劃分方案” 214 

第13章 如何分層 217 
13.1 分層架構 218 
13.1.1 常見模式：展現層、業務層、數據層 218 
13.1.2 案例一則 218 
13.1.3 常見模式：UI層、SI層、PD層、DM層 219 
13.1.4 案例一則 220 
13.2 分層架構實踐技巧 221 
13.2.1 設計思想：分層架構的“封裝外部交互”思想 221 
13.2.2 實踐技巧：設計分層架構，從上下文圖開始 221 
13.3 實際應用（11）——對比MailProxy案例的 4種模塊劃分設計 223 
13.3.1 設計 223 
13.3.2 設計的優點、缺點 224 

第14章 用例驅動的模塊劃分過程 225 
14.1 描述需求的序列圖 vs. 描述設計的序列圖 225 
14.1.1 描述“內外對話” vs. 描述“內部協作” 226 
14.1.2 《用例規約》這樣描述“內外對話” 227 
14.2 用例驅動的模塊劃分過程 228 
14.2.1 核心原理：從用例到類，再到模塊 228 
14.2.2 第1步：實現用例需要哪些類 231 
14.2.3 第2步：這些類應該劃歸哪些模塊 235 
14.3 實際應用（12）——對比MailProxy案例的 4種模塊劃分設計 236 
14.3.1 設計 236 
14.3.2 設計的優點、缺點 236 

第15章 模塊劃分的4步驟方法——運用層、模塊、功能 模塊、用例驅動 238 
15.1 像專家一樣思考 238 
15.1.1 自頂向下vs.自底向上，垂直切分vs.水平切分 238 
15.1.2 橫切豎割，並不矛盾 239 
15.2 模塊劃分的4步驟方法——EDD方法 241 
15.2.1 封裝驅動設計的4個步驟 241 
15.2.2 細粒度模塊的劃分技巧 242 
15.3 實際應用（13）——對比MailProxy案例的4種模塊劃分設計 245 
15.3.1 設計 245 
15.3.2 設計的優點、缺點 246