《軟體架構設計（第2版）——程式設計師向架構師轉型必備》是2012年7月電子工業出版社出版的圖書，作者是溫昱。
基本介紹
- 書名：軟體架構設計（第2版）——程式設計師向架構師轉型必備
- 作者：溫昱
- ISBN：9787121170874
- 頁數：256
- 定價：39.00元
- 出版社：電子工業出版社
- 出版時間：2012年7月
- 開本：16開
內容簡介,專家推薦,作者基金,圖書目錄,
內容簡介
本書圍繞“軟體架構設計”主題，從“程式設計師”成長的視角，深入淺出地講述了架構師的修煉之道。從“基礎篇”、到“設計過程篇”、到“模組劃分專題”，本書覆蓋了架構設計的關鍵技能項，並且對於架構設計過程中可能出現的各種問題給與了解答。
本書對於有志於成為架構師的程式設計師們具有非常有效的指導意義，對於已經成為架構師的同行們系統化規範架構設計也是一本很好的教材。
專家推薦
（以姓氏筆劃為序）
與溫昱先生初識於一次部門內訓，金融機構套用信息技術日久，但業務發展之快仍需信息技術部門不斷思索如何提供有力的技術支持，當時系統設計人員思路難成一致，故邀請先生來講述所得，先生講座生動有趣，案例均為實踐中心得，有助於一線設計人員在低頭幹事之餘，能夠抬頭看路，從架構高度理解和看待日常工作，《軟體架構設計（第2版）》同樣著眼於研發實踐，不作黃鐘大呂之音，而以一觴一詠暢敘分享一線設計師的感悟體會。此書值得一看，作者亦值得一晤！
——朱曉光 中國建設銀行 北京開發中心 處長
在廈門，曾和溫老師有過4天晚上的坐而論道，從技術到業界、從數據模型到軟體重構、從職業觀到心理學，彼此頗多啟發。第一時間收到本書的電子版，讀來流暢易懂，勝似面晤對談。本書內容務實、技能梳理清晰，實乃軟體開發者職業生涯發展的重要參考。
——朱志 中國建設銀行 廈門開發中心總工辦
基於軟體架構的開發模式，作為軟體開發的最佳實踐之一，越來越得到各行各業的重視和關注，但遺憾的是理解其精髓和內涵的人太少。溫老師作為軟體架構思想的傳播者和推動者，在這本書中，對程式設計師如何成長為優秀的架構師給出了非常具體的指導原則和實現方法，是國內不可多得的真正將軟體架構思想闡述如此精準的實踐指導書。作為一名軟體行業的從業者，我強烈推薦給大家。
——李哲洙 博士 東軟集團 電信事業部 網管產品與系統部部長
這本書以架構設計人員實際工作流程為線索，詳細闡述了邏輯架構和物理架構視圖的重要性及其在架構設計中的套用方法。此外，本書從實踐的角度，給出了架構設計的三個原則和6大步驟，並以具體實踐過程為指導，給出了架構設計從需求分析到最後的架構設計、架構驗證的完整的架構設計生命周期的實踐方法，對軟體研發項目團隊和架構師的研發實踐工作具有很好的指導意義。
——楊勇 中興通訊 業務研究院 平台總工
從事軟體工作近十年，由軟體功能模組的程式設計師開始，到獨立負責幾個軟體項目的設計開發，一直對軟體架構設計比較關注，有幸聽了溫昱老師的“軟體架構設計”講座，頓感茅塞頓開，再次閱讀溫老師的《軟體架構設計》，對架構設計有了更深的感悟。如果你對軟體架構設計感覺朦朦朧朧，溫先生的《軟體架構設計（第2版）》定能讓你撥開雲霧見青天。
——楊為祿 南京國睿安泰信科技股份有限公司 一線軟體工程師
近年來，閱讀了諸多系統、需求、架構類的書籍資料，溫老師的幾本書簡明扼要，見解獨到，頗多啟發。“橫看成嶺側成峰，遠近高低各不同”，大系統架構（體系結構）包括系統組分、組分間的關係，以及演化等三要素；溫老師在本書中給出了典型視角、典型模式、典型過程等實踐指南。有志創造系統，賦予軟體靈魂的架構師，當讀此書。
——張雪松 中國電子科學研究院 複雜大系統研究與仿真
架構是很玄的東西，成為優秀的架構師也是大部分程式設計師的理想。溫昱先生這本書的特點就是從程式設計師角度，深入淺出地講述了架構師的修煉之道。程式設計師與架構師區別的最重要一點是看待事物的角度和處理方法，優秀的程式設計師按照本書的方法，在日常工作中一步步實踐，有助於培養出架構師的能力，從而逐步成長成為架構師。架構的目標是為了溝通和交流，溫先生也深刻地領悟到這一架構設計的根本目標，並將這一目標轉化為方法論。架構設計不是給自己看的，而是為了與客戶、領導和團隊溝通，本書的重點在於架構設計實踐，從用例、需求分析、概念模型、細化模型等一步步地指導如何完成架構設計，並且對於架構設計過程中可能出現的各種問題給予了解答。本書對於有志於成為架構師的程式設計師們具有非常有效的指導意義，對於已經成為架構師的同行們系統化規範架構設計也是一本很好的教材。
——錢煜明 中興通訊 業務研究院 移動網際網路總工程師
早在2009年的時候就讀過溫老師的《軟體架構設計》第一版，2011年有幸請到溫老師來公司主講“軟體架構設計”，幸有當面請教的機會，溫老師對軟體架構獨特的授課方法和深厚的功底讓我如沐春風、豁然開朗，頗有幾分“頓悟”之感。
五年磨一劍，如今有幸搶先拜讀溫老師的《軟體架構設計》第二版，更是被書中內容所折服。書中融合了作者多年來在一線的實踐和培訓經驗，深入淺出地闡釋了什麼是軟體架構，手把手教你從客戶需求入手順暢地設計出高可用的軟體架構，讓你讀完本書後情不自禁地感嘆：“原來軟體架構設計並沒有那么高深莫測！”該書理論和實踐並重，是一本不可多得的軟體架構設計的指導書籍。
——崔朝輝 東軟集團 技術戰略與發展部 資深顧問
站得足夠高，才能看得足夠遠。當今IT的架構設計思想理念已經是經過數次洗禮之後的結晶，而溫昱先生抓住了這一結晶生命體的真正骨架，並深入淺出地匯集成這本書。有了這本書，你就可以依據自己的Project來高效地添加血肉，構建出獨特的有機生命體。
——諶晏生 廣州從興 電力事業部 一線軟體設計師
作者基金
溫昱 資深諮詢顧問，軟體架構專家。軟體架構思想的傳播者和積極推動者，中國軟體技術大會傑出貢獻專家。十五年系統規劃、架構設計和研發管理經驗，在金融、航空、多媒體、電信、中間件平台等領域負責和參與多個大型系統的規劃、設計、開發與管理。
圖書目錄
第1章 從程式設計師到架構師
1.1 軟體業人才結構
1.1.1 金字塔型，還是橄欖型？
1.1.2 從程式設計師向架構師轉型
1.2 本書價值
1.2.1 閱讀路徑1：架構設計入門
1.2.2 閱讀路徑2：領會大系統架構設計
1.2.3 閱讀路徑3：從需求到架構的全過程
1.2.4 閱讀路徑4：結合工作，解決實際問題
第1部分 基本概念篇
第2章 解析軟體架構概念
2.1 軟體架構概念的分類
2.1.1 組成派
2.1.2 決策派
2.1.3 軟體架構概念大觀
2.2 概念思想的解析
2.2.1 軟體架構關注分割與互動
2.2.2 軟體架構是一系列有層次的決策
2.2.3 系統、子系統、框架都可以有架構
2.3 實際套用（1）——團隊對架構看法不一怎么辦
2.3.1 結合手上的實際工作來理解架構的含義
2.3.2 這樣理解“架構”對嗎
2.3.3 工作中找答案：先看部分設計
2.3.4 工作中找答案：反觀架構概念的體現
第3章 理解架構設計視圖
3.1 軟體架構為誰而設計
3.1.1 為用戶而設計
3.1.2 為客戶而設計
3.1.3 為開發人員而設計
3.1.4 為管理人員而設計
3.1.5 總結
3.2 理解架構設計視圖
3.2.1 架構視圖
3.2.2 一個直觀的例子
3.2.3 多組涉眾，多個視圖
3.3 運用“邏輯視圖+物理視圖”設計架構
3.3.1 邏輯架構
3.3.2 物理架構
3.3.3 從“邏輯架構+物理架構”到設計實現
3.4 實際套用（2）——開發人員如何快速成長
3.4.1 開發人員應該多嘗試設計
3.4.2 實驗項目：案例背景、訓練目標
3.4.3 邏輯架構設計（疊代1）
3.4.4 物理架構設計（疊代1）
3.4.5 邏輯架構設計（疊代2）
3.4.6 物理架構設計（疊代2）
第2部分 實踐過程篇
第4章 架構設計過程
4.1 架構設計的實踐脈絡
4.1.1 洞察節奏：3個原則
4.1.2 掌握過程：6個步驟
4.2 架構設計的速查手冊
4.2.1 需求分析
4.2.2 領域建模
4.2.3 確定關鍵需求
4.2.4 概念架構設計
4.2.5 細化架構設計
4.2.6 架構驗證
第5章 需求分析
5.1 需求開發（上）——願景分析
5.1.1 從概念化階段說起
5.1.2 願景
5.1.3 上下文圖
5.1.4 願景分析實踐要領
5.2 需求開發（下）——需求分析
5.2.1 需求捕獲vs.需求分析vs.系統分析
5.2.2 需求捕獲及成果
5.2.3 需求分析及成果
5.2.4 系統分析及成果
5.3 掌握的需求全不全
5.3.1 二維需求觀與ADMEMS矩陣
5.3.2 功能
5.3.3 質量
5.3.4 約束
5.4 從需求向設計轉化的“密碼”
5.4.1 “理性設計”還是“拍腦袋”
5.4.2 功能：職責協作鏈
5.4.3 質量：完善驅動力
5.4.4 約束：設計並不自由
5.5 實際套用（3）——PM Suite貫穿案例之需求分析
5.5.1 PM Suite案例背景介紹
5.5.2 第1步：明確係統目標
5.5.3 第2步：範圍 + Feature + 上下文圖
5.5.4 第3步：畫用例圖
5.5.5 第4步：寫用例規約
5.5.6 插曲：需求啟發與需求驗證
5.5.7 插曲：非功能需求
5.5.8 《需求規格》與基於ADMEMS矩陣的需求評審
第6章 用例與需求
6.1 用例技術族
6.1.1 用例圖
6.1.2 用例簡述、用戶故事
6.1.3 用例規約
6.1.4 用例實現、魯棒圖
6.1.54種技術的關係
6.2 用例技術族的套用場景
6.2.1 用例與需求分析
6.2.2 用例與需求文檔
6.2.3 用例與需求變更
6.3 實際套用（4）——用例建模夠不夠？流程建模要不要
6.3.1 軟體事業部的故事
6.3.2 小型方法：需求分析的三套實踐論（上）
6.3.3 中型方法：需求分析的三套實踐論（中）
6.3.4 大型方法：需求分析的三套實踐論（下）
6.3.5 PM Suite套用一幕
第7章 領域建模
7.1 什麼是領域模型
7.1.1 領域模型“是什麼”
7.1.2 領域模型“什麼樣”
7.1.3 領域模型“為什麼”
7.2 需求人員視角——促進用戶溝通、解決分析癱瘓
7.2.1 領域建模與需求分析的關係
7.2.2 溝通不足
7.2.3 分析癱瘓
7.2.4 案例：多步領域建模，熟悉陌生領域
7.3 開發人員視角——破解“領域知識不足”死結
7.3.1 領域模型作為“理解領域的手段”
7.3.2 案例：從辭彙表到領域模型
7.4 實際套用（5）——功能決定如何建模，模型決定功能擴展
7.4.1 案例：模型決定功能擴展
7.4.2 實踐：功能決定如何建模
7.4.3 PM Suite領域建模實錄（1）——類圖
7.4.4 PM Suite領域建模實錄（2）——狀態圖
7.4.5 PM Suite領域建模實錄（3）——可擴展性
第8章 確定關鍵需求
8.1 眾說紛紜——什麼決定了架構
8.1.1 用例驅動論
8.1.2 質量決定論
8.1.3 經驗決定論
8.2 真知灼見——關鍵需求決定架構
8.2.1 “目標錯誤”比“遺漏需求”更糟糕
8.2.2 關鍵需求決定架構，其餘需求驗證架構
8.3 付諸行動——如何確定關鍵需求
8.3.1 確定關鍵質量
8.3.2 確定關鍵功能
8.4 實際套用（6）——小系統與大系統的架構分水嶺
8.4.1 架構師的“拿來主義”困惑
8.4.2 場景1：小型PMIS（項目型ISV背景）
8.4.3 場景2：大型PM Suite（產品型ISV背景）
8.4.4 場景3：多個自主產品組成的方案（例如IBM）
8.4.5 “拿來主義”雖好，但要合適才行
第9章 概念架構設計
9.1 概念架構是什麼
9.1.1 概念架構是直指目標的設計思想、重大選擇
9.1.2 案例1：汽車電子AUTOSAR——跨平台復用
9.1.3 案例2：騰訊QQvideo架構——高性能
9.1.4 案例3：微軟MFC架構——簡化開發
9.1.5 總結
9.2 概念架構設計概述
9.2.1 “關鍵需求”進，“概念架構”出
9.2.2 概念架構≠理想化架構
9.2.3 概念架構≠細化架構
9.3 左手功能——概念架構設計（上）
9.3.1 什麼樣的鴻溝，架什麼樣的橋
9.3.2 魯棒圖“是什麼”
9.3.3 魯棒圖“畫什麼”
9.3.4 魯棒圖“怎么畫”
9.4 右手質量——概念架構設計（下）
9.4.1 再談什麼樣的鴻溝，架什麼樣的橋
9.4.2 場景思維
9.4.3 場景思維的工具
9.4.4 目標—場景—決策表套用舉例
9.5 概念架構設計實踐要領
9.5.1 要領1：功能需求與質量需求並重
9.5.2 要領2：概念架構設計的1個決定、4個選擇
9.5.3 要領3：備選設計
9.6 實際套用（7）——PM Suite貫穿案例之概念架構設計
9.6.1 第1步：通過初步設計，探索架構風格和高層分割
9.6.2 第2步：選擇架構風格，劃分頂級子系統
9.6.3 第3步：開發技術、集成技術與二次開發技術的選型
9.6.4 第4步：評審3個備選架構，敲定概念架構方案
第10章 細化架構設計
10.1 從2視圖方法到5視圖方法
10.1.1 回顧：2視圖方法
10.1.2 進階：5視圖方法
10.2 程式設計師向架構師轉型的關鍵突破——學會系統思考
10.2.1 系統思考之“從需求到設計”
10.2.2 系統思考之“5個設計視圖”
10.35視圖方法實踐——5個視圖、15個設計任務
10.3.1 邏輯架構=模組劃分+接口定義+領域模型
10.3.2 開發架構=技術選型+檔案劃分+編譯關係
10.3.3 物理架構=硬體分布+軟體部署+方案最佳化
10.3.4 運行架構=技術選型+控制流劃分+同步關係
10.3.5 數據架構=技術選型+存儲格式+數據分布
10.4 實際套用（8）——PM Suite貫穿案例之細化架構設計
10.4.1 PM Suite接下來的設計任務
10.4.2 客戶端設計的相關說明
10.4.3 細化領域模型時應注意的兩點
第11章 架構驗證
11.1 原型技術
11.1.1 水平原型vs.垂直原型，拋棄原型vs.演進原型
11.1.2 水平拋棄原型
11.1.3 水平演進原型
11.1.4 垂直拋棄原型
11.1.5 垂直演進原型
11.2 架構驗證
11.2.1 原型法
11.2.2 框架法
11.2.3 測試運行期質量，評審開發期質量
第3部分 模組劃分專題
第12章 粗粒度“功能模組”劃分
12.1 功能樹
12.1.1 什麼是功能樹
12.1.2 功能分解≠結構分解
12.2 藉助功能樹，劃分粗粒度“功能模組”
12.2.1 核心原理：從“功能組”到“功能模組”
12.2.2 第1步：獲得功能樹
12.2.3 第2步：評審功能樹
12.2.4 第3步：粗粒度“功能模組”劃分
12.3 實際套用（9）——對比MailProxy案例的4種模組劃分設計
12.3.1 設計
12.3.2 設計的優點、缺點
12.4 實際套用（10）——做總體，要提交啥樣的“子系統劃分方案”
第13章 如何分層
13.1 分層架構
13.1.1 常見模式：展現層、業務層、數據層
13.1.2 案例一則
13.1.3 常見模式：UI層、SI層、PD層、DM層
13.1.4 案例一則
13.2 分層架構實踐技巧
13.2.1 設計思想：分層架構的“封裝外部互動”思想
13.2.2 實踐技巧：設計分層架構，從上下文圖開始
13.3 實際套用（11）——對比MailProxy案例的 4種模組劃分設計
13.3.1 設計
13.3.2 設計的優點、缺點
第14章 用例驅動的模組劃分過程
14.1 描述需求的序列圖 vs. 描述設計的序列圖
14.1.1 描述“內外對話” vs. 描述“內部協作”
14.1.2 《用例規約》這樣描述“內外對話”
14.2 用例驅動的模組劃分過程
14.2.1 核心原理：從用例到類，再到模組
14.2.2 第1步：實現用例需要哪些類
14.2.3 第2步：這些類應該劃歸哪些模組
14.3 實際套用（12）——對比MailProxy案例的 4種模組劃分設計
14.3.1 設計
14.3.2 設計的優點、缺點
第15章 模組劃分的4步驟方法——運用層、模組、功能 模組、用例驅動
15.1 像專家一樣思考
15.1.1 自頂向下vs.自底向上，垂直切分vs.水平切分
15.1.2 橫切豎割，並不矛盾
15.2 模組劃分的4步驟方法——EDD方法
15.2.1 封裝驅動設計的4個步驟
15.2.2 細粒度模組的劃分技巧
15.3 實際套用（13）——對比MailProxy案例的4種模組劃分設計
15.3.1 設計
15.3.2 設計的優點、缺點
1.1 軟體業人才結構
1.1.1 金字塔型，還是橄欖型？
1.1.2 從程式設計師向架構師轉型
1.2 本書價值
1.2.1 閱讀路徑1：架構設計入門
1.2.2 閱讀路徑2：領會大系統架構設計
1.2.3 閱讀路徑3：從需求到架構的全過程
1.2.4 閱讀路徑4：結合工作，解決實際問題
第1部分 基本概念篇
第2章 解析軟體架構概念
2.1 軟體架構概念的分類
2.1.1 組成派
2.1.2 決策派
2.1.3 軟體架構概念大觀
2.2 概念思想的解析
2.2.1 軟體架構關注分割與互動
2.2.2 軟體架構是一系列有層次的決策
2.2.3 系統、子系統、框架都可以有架構
2.3 實際套用（1）——團隊對架構看法不一怎么辦
2.3.1 結合手上的實際工作來理解架構的含義
2.3.2 這樣理解“架構”對嗎
2.3.3 工作中找答案：先看部分設計
2.3.4 工作中找答案：反觀架構概念的體現
第3章 理解架構設計視圖
3.1 軟體架構為誰而設計
3.1.1 為用戶而設計
3.1.2 為客戶而設計
3.1.3 為開發人員而設計
3.1.4 為管理人員而設計
3.1.5 總結
3.2 理解架構設計視圖
3.2.1 架構視圖
3.2.2 一個直觀的例子
3.2.3 多組涉眾，多個視圖
3.3 運用“邏輯視圖+物理視圖”設計架構
3.3.1 邏輯架構
3.3.2 物理架構
3.3.3 從“邏輯架構+物理架構”到設計實現
3.4 實際套用（2）——開發人員如何快速成長
3.4.1 開發人員應該多嘗試設計
3.4.2 實驗項目：案例背景、訓練目標
3.4.3 邏輯架構設計（疊代1）
3.4.4 物理架構設計（疊代1）
3.4.5 邏輯架構設計（疊代2）
3.4.6 物理架構設計（疊代2）
第2部分 實踐過程篇
第4章 架構設計過程
4.1 架構設計的實踐脈絡
4.1.1 洞察節奏：3個原則
4.1.2 掌握過程：6個步驟
4.2 架構設計的速查手冊
4.2.1 需求分析
4.2.2 領域建模
4.2.3 確定關鍵需求
4.2.4 概念架構設計
4.2.5 細化架構設計
4.2.6 架構驗證
第5章 需求分析
5.1 需求開發（上）——願景分析
5.1.1 從概念化階段說起
5.1.2 願景
5.1.3 上下文圖
5.1.4 願景分析實踐要領
5.2 需求開發（下）——需求分析
5.2.1 需求捕獲vs.需求分析vs.系統分析
5.2.2 需求捕獲及成果
5.2.3 需求分析及成果
5.2.4 系統分析及成果
5.3 掌握的需求全不全
5.3.1 二維需求觀與ADMEMS矩陣
5.3.2 功能
5.3.3 質量
5.3.4 約束
5.4 從需求向設計轉化的“密碼”
5.4.1 “理性設計”還是“拍腦袋”
5.4.2 功能：職責協作鏈
5.4.3 質量：完善驅動力
5.4.4 約束：設計並不自由
5.5 實際套用（3）——PM Suite貫穿案例之需求分析
5.5.1 PM Suite案例背景介紹
5.5.2 第1步：明確係統目標
5.5.3 第2步：範圍 + Feature + 上下文圖
5.5.4 第3步：畫用例圖
5.5.5 第4步：寫用例規約
5.5.6 插曲：需求啟發與需求驗證
5.5.7 插曲：非功能需求
5.5.8 《需求規格》與基於ADMEMS矩陣的需求評審
第6章 用例與需求
6.1 用例技術族
6.1.1 用例圖
6.1.2 用例簡述、用戶故事
6.1.3 用例規約
6.1.4 用例實現、魯棒圖
6.1.54種技術的關係
6.2 用例技術族的套用場景
6.2.1 用例與需求分析
6.2.2 用例與需求文檔
6.2.3 用例與需求變更
6.3 實際套用（4）——用例建模夠不夠？流程建模要不要
6.3.1 軟體事業部的故事
6.3.2 小型方法：需求分析的三套實踐論（上）
6.3.3 中型方法：需求分析的三套實踐論（中）
6.3.4 大型方法：需求分析的三套實踐論（下）
6.3.5 PM Suite套用一幕
第7章 領域建模
7.1 什麼是領域模型
7.1.1 領域模型“是什麼”
7.1.2 領域模型“什麼樣”
7.1.3 領域模型“為什麼”
7.2 需求人員視角——促進用戶溝通、解決分析癱瘓
7.2.1 領域建模與需求分析的關係
7.2.2 溝通不足
7.2.3 分析癱瘓
7.2.4 案例：多步領域建模，熟悉陌生領域
7.3 開發人員視角——破解“領域知識不足”死結
7.3.1 領域模型作為“理解領域的手段”
7.3.2 案例：從辭彙表到領域模型
7.4 實際套用（5）——功能決定如何建模，模型決定功能擴展
7.4.1 案例：模型決定功能擴展
7.4.2 實踐：功能決定如何建模
7.4.3 PM Suite領域建模實錄（1）——類圖
7.4.4 PM Suite領域建模實錄（2）——狀態圖
7.4.5 PM Suite領域建模實錄（3）——可擴展性
第8章 確定關鍵需求
8.1 眾說紛紜——什麼決定了架構
8.1.1 用例驅動論
8.1.2 質量決定論
8.1.3 經驗決定論
8.2 真知灼見——關鍵需求決定架構
8.2.1 “目標錯誤”比“遺漏需求”更糟糕
8.2.2 關鍵需求決定架構，其餘需求驗證架構
8.3 付諸行動——如何確定關鍵需求
8.3.1 確定關鍵質量
8.3.2 確定關鍵功能
8.4 實際套用（6）——小系統與大系統的架構分水嶺
8.4.1 架構師的“拿來主義”困惑
8.4.2 場景1：小型PMIS（項目型ISV背景）
8.4.3 場景2：大型PM Suite（產品型ISV背景）
8.4.4 場景3：多個自主產品組成的方案（例如IBM）
8.4.5 “拿來主義”雖好，但要合適才行
第9章 概念架構設計
9.1 概念架構是什麼
9.1.1 概念架構是直指目標的設計思想、重大選擇
9.1.2 案例1：汽車電子AUTOSAR——跨平台復用
9.1.3 案例2：騰訊QQvideo架構——高性能
9.1.4 案例3：微軟MFC架構——簡化開發
9.1.5 總結
9.2 概念架構設計概述
9.2.1 “關鍵需求”進，“概念架構”出
9.2.2 概念架構≠理想化架構
9.2.3 概念架構≠細化架構
9.3 左手功能——概念架構設計（上）
9.3.1 什麼樣的鴻溝，架什麼樣的橋
9.3.2 魯棒圖“是什麼”
9.3.3 魯棒圖“畫什麼”
9.3.4 魯棒圖“怎么畫”
9.4 右手質量——概念架構設計（下）
9.4.1 再談什麼樣的鴻溝，架什麼樣的橋
9.4.2 場景思維
9.4.3 場景思維的工具
9.4.4 目標—場景—決策表套用舉例
9.5 概念架構設計實踐要領
9.5.1 要領1：功能需求與質量需求並重
9.5.2 要領2：概念架構設計的1個決定、4個選擇
9.5.3 要領3：備選設計
9.6 實際套用（7）——PM Suite貫穿案例之概念架構設計
9.6.1 第1步：通過初步設計，探索架構風格和高層分割
9.6.2 第2步：選擇架構風格，劃分頂級子系統
9.6.3 第3步：開發技術、集成技術與二次開發技術的選型
9.6.4 第4步：評審3個備選架構，敲定概念架構方案
第10章 細化架構設計
10.1 從2視圖方法到5視圖方法
10.1.1 回顧：2視圖方法
10.1.2 進階：5視圖方法
10.2 程式設計師向架構師轉型的關鍵突破——學會系統思考
10.2.1 系統思考之“從需求到設計”
10.2.2 系統思考之“5個設計視圖”
10.35視圖方法實踐——5個視圖、15個設計任務
10.3.1 邏輯架構=模組劃分+接口定義+領域模型
10.3.2 開發架構=技術選型+檔案劃分+編譯關係
10.3.3 物理架構=硬體分布+軟體部署+方案最佳化
10.3.4 運行架構=技術選型+控制流劃分+同步關係
10.3.5 數據架構=技術選型+存儲格式+數據分布
10.4 實際套用（8）——PM Suite貫穿案例之細化架構設計
10.4.1 PM Suite接下來的設計任務
10.4.2 客戶端設計的相關說明
10.4.3 細化領域模型時應注意的兩點
第11章 架構驗證
11.1 原型技術
11.1.1 水平原型vs.垂直原型，拋棄原型vs.演進原型
11.1.2 水平拋棄原型
11.1.3 水平演進原型
11.1.4 垂直拋棄原型
11.1.5 垂直演進原型
11.2 架構驗證
11.2.1 原型法
11.2.2 框架法
11.2.3 測試運行期質量，評審開發期質量
第3部分 模組劃分專題
第12章 粗粒度“功能模組”劃分
12.1 功能樹
12.1.1 什麼是功能樹
12.1.2 功能分解≠結構分解
12.2 藉助功能樹，劃分粗粒度“功能模組”
12.2.1 核心原理：從“功能組”到“功能模組”
12.2.2 第1步：獲得功能樹
12.2.3 第2步：評審功能樹
12.2.4 第3步：粗粒度“功能模組”劃分
12.3 實際套用（9）——對比MailProxy案例的4種模組劃分設計
12.3.1 設計
12.3.2 設計的優點、缺點
12.4 實際套用（10）——做總體，要提交啥樣的“子系統劃分方案”
第13章 如何分層
13.1 分層架構
13.1.1 常見模式：展現層、業務層、數據層
13.1.2 案例一則
13.1.3 常見模式：UI層、SI層、PD層、DM層
13.1.4 案例一則
13.2 分層架構實踐技巧
13.2.1 設計思想：分層架構的“封裝外部互動”思想
13.2.2 實踐技巧：設計分層架構，從上下文圖開始
13.3 實際套用（11）——對比MailProxy案例的 4種模組劃分設計
13.3.1 設計
13.3.2 設計的優點、缺點
第14章 用例驅動的模組劃分過程
14.1 描述需求的序列圖 vs. 描述設計的序列圖
14.1.1 描述“內外對話” vs. 描述“內部協作”
14.1.2 《用例規約》這樣描述“內外對話”
14.2 用例驅動的模組劃分過程
14.2.1 核心原理：從用例到類，再到模組
14.2.2 第1步：實現用例需要哪些類
14.2.3 第2步：這些類應該劃歸哪些模組
14.3 實際套用（12）——對比MailProxy案例的 4種模組劃分設計
14.3.1 設計
14.3.2 設計的優點、缺點
第15章 模組劃分的4步驟方法——運用層、模組、功能 模組、用例驅動
15.1 像專家一樣思考
15.1.1 自頂向下vs.自底向上，垂直切分vs.水平切分
15.1.2 橫切豎割，並不矛盾
15.2 模組劃分的4步驟方法——EDD方法
15.2.1 封裝驅動設計的4個步驟
15.2.2 細粒度模組的劃分技巧
15.3 實際套用（13）——對比MailProxy案例的4種模組劃分設計
15.3.1 設計
15.3.2 設計的優點、缺點
