《恰如其分的軟件架構(gòu)》的作者在探討比較多種架構(gòu)風(fēng)格的差異和利弊的基礎(chǔ)上,結(jié)合自己的工作經(jīng)驗,提煉出通過風(fēng)險驅(qū)動的軟件架構(gòu)設(shè)計方法,旨在彌補敏捷開發(fā)方法在實際工程應(yīng)用中的不足。本書將理論與實踐相結(jié)合,不僅條理清晰地描述了設(shè)計軟件架設(shè)的各種思路,而且詳細(xì)介紹了經(jīng)過實踐檢驗的建模方法和架構(gòu)分析技巧。
George Fairbanks在卡內(nèi)基·梅隆大學(xué)獲得軟件工程專業(yè)博士學(xué)位,現(xiàn)任RhinoResearch公司董事長。RhinoResearch是一家專門提供軟件開發(fā)培訓(xùn)及咨詢的公司,總部設(shè)在美國科羅拉多州博爾德市。
張逸是ThoughtWorks高級咨詢師,程序員。InfoQ中文站編輯。著譯作包括《軟件設(shè)計精要與模式》《WCF服務(wù)編程》《Java設(shè)計模式》以及評注版《重構(gòu):改善既有代碼的設(shè)計》。目前居住于成都。
倪健是eBaoTech應(yīng)用架構(gòu)師,程序員。著作包括《簡單之美:軟件開發(fā)實踐者的思考》《IT項目管理那些事兒》(與人合著)。目前居住于上海。
第1章 概述
1.1 分治、知識與抽象
1.2 軟件架構(gòu)的三個案例
1.3 反思
1.4 視角轉(zhuǎn)換
1.5 架構(gòu)師構(gòu)建架構(gòu)
1.6 風(fēng)險驅(qū)動的軟件架構(gòu)
1.7 敏捷開發(fā)者的架構(gòu)
1.8 關(guān)于本書
第2章 軟件架構(gòu)
2.1 何為軟件架構(gòu)?
2.2 軟件架構(gòu)為何重要
2.3 架構(gòu)何時重要?
2.4 推定架構(gòu)
2.5 如何運用軟件架構(gòu)?
第1章 概述
1.1 分治、知識與抽象
1.2 軟件架構(gòu)的三個案例
1.3 反思
1.4 視角轉(zhuǎn)換
1.5 架構(gòu)師構(gòu)建架構(gòu)
1.6 風(fēng)險驅(qū)動的軟件架構(gòu)
1.7 敏捷開發(fā)者的架構(gòu)
1.8 關(guān)于本書
第2章 軟件架構(gòu)
2.1 何為軟件架構(gòu)?
2.2 軟件架構(gòu)為何重要
2.3 架構(gòu)何時重要?
2.4 推定架構(gòu)
2.5 如何運用軟件架構(gòu)?
2.6 架構(gòu)無關(guān)的設(shè)計
2.7 專注架構(gòu)的設(shè)計
2.8 提升架構(gòu)的設(shè)計
2.9 大型組織中的架構(gòu)
2.10 結(jié)論
2.11 延伸閱讀
第3章 風(fēng)險驅(qū)動模型
3.1 風(fēng)險驅(qū)動模型是什么?
3.2 你現(xiàn)在采用風(fēng)險驅(qū)動了嗎?
3.3 風(fēng)險
3.4 技術(shù)
3.5 選擇技術(shù)的指導(dǎo)原則
3.6 何時停止
3.7 計劃式設(shè)計與演進式設(shè)計
3.8 軟件開發(fā)過程
3.9 理解過程變化
3.10 風(fēng)險驅(qū)動模型與軟件開發(fā)過程
3.11 應(yīng)用于敏捷過程
3.12 風(fēng)險與架構(gòu)重構(gòu)
3.13 風(fēng)險驅(qū)動模型的替代方案
3.14 結(jié)論
3.15 延伸閱讀
第4章 實例:家庭媒體播放器
4.1 團隊溝通
4.2 COTS組件的集成
4.3 元數(shù)據(jù)一致性
4.4 結(jié)論
第5章 建模建議
5.1 專注于風(fēng)險
5.2 理解你的架構(gòu)
5.3 傳播架構(gòu)技能
5.4 作出合理的架構(gòu)決策
5.5 避免預(yù)先大量設(shè)計
5.6 避免自頂向下設(shè)計
5.7 余下的挑戰(zhàn)
5.8 特性和風(fēng)險:一個故事
第6章 工程師使用模型
6.1 規(guī)模與復(fù)雜度需要抽象
6.2 抽象提供洞察力和解決手段
6.3 分析系統(tǒng)質(zhì)量
6.4 模型忽略細(xì)節(jié)
6.5 模型能夠增強推理
6.6 提問在前,建模在后
6.7 小結(jié)
6.8 延伸閱讀
第7章 軟件架構(gòu)的概念模型
7.1 規(guī)范化模型結(jié)構(gòu)
7.2 領(lǐng)域模型、設(shè)計模型和代碼模型
7.3 指定與細(xì)化關(guān)系
7.4 主模型的視圖
7.5 組織模型的其他方式
7.6 業(yè)務(wù)建模
7.7 UML的用法
7.8 小結(jié)
7.9 延伸閱讀
第8章 領(lǐng)域模型
8.1 領(lǐng)域與架構(gòu)的關(guān)系
8.2 信息模型
8.3 導(dǎo)航和不變量
8.4 快照
8.5 功能場景
8.6 小結(jié)
8.7 延伸閱讀
第9章 設(shè)計模型
9.1 設(shè)計模型
9.2 邊界模型
9.3 內(nèi)部模型
9.4 質(zhì)量屬性
9.5 Yinzer系統(tǒng)的設(shè)計之旅
9.6 視圖類型
9.7 動態(tài)架構(gòu)模型
9.8 架構(gòu)描述語言
9.9 小結(jié)
9.10 深入閱讀
第10章 代碼模型
10.1 模型-代碼差異
10.2 一致性管理
10.3 架構(gòu)明顯的編碼風(fēng)格
10.4 在代碼中表達設(shè)計意圖
10.5 模型嵌入代碼原理
10.6 表達什么
10.7 在代碼中表達設(shè)計意圖的模式
10.8 電子郵件處理系統(tǒng)預(yù)演
10.9 小結(jié)
第11章 封裝和分割
11.1 多層級故事
11.2 層級和分割
11.3 分解策略
11.4 有效封裝
11.5 創(chuàng)建封裝接口
11.6 小結(jié)
11.7 深入閱讀
第12章 模型元素
12.1 和部署相關(guān)的元素
12.2 組件
12.3 組件裝配
12.4 連接器
12.5 設(shè)計決策
12.6 功能場景
12.7 (不變量(約束)
12.8 模塊
12.9 端口
12.10 質(zhì)量屬性
12.11 質(zhì)量屬性場景
12.12 職責(zé)
12.13 權(quán)衡
12.14 小結(jié)
第13章 模型關(guān)系
13.1 投影(視圖)關(guān)系
13.2 分割關(guān)系
13.3 組合關(guān)系
13.4 分類關(guān)系
13.5 泛化關(guān)系
13.6 指定關(guān)系
13.7 細(xì)化關(guān)系
13.8 綁定關(guān)系
13.9 依賴關(guān)系
13.10 使用關(guān)系
13.11 小結(jié)
13.12 深入閱讀
第14章 架構(gòu)風(fēng)格
14.1 優(yōu)勢
14.2 柏拉圖式風(fēng)格對體驗式風(fēng)格
14.3 約束和以架構(gòu)為中心的設(shè)計
14.4 模式對風(fēng)格
14.5 風(fēng)格目錄
14.6 分層風(fēng)格
14.7 大泥球風(fēng)格
14.8 管道-過濾器風(fēng)格
14.9 批量順序處理風(fēng)格
14.10 以模型為中心的風(fēng)格
14.11 分發(fā)-訂閱風(fēng)格
14.12 客戶端-服務(wù)器風(fēng)格和多層
14.13 對等風(fēng)格
14.14 map-reduce風(fēng)格
14.15 鏡像,支架和農(nóng)場風(fēng)格
14.16 小結(jié)
14.17 深入閱讀
第15章 使用架構(gòu)模型
15.1 理想的模型特性
15.2 和視圖一起工作
15.3 改善視圖質(zhì)量
15.4 提高圖的質(zhì)量
15.5 測試和證明
15.6 分析架構(gòu)模型
15.7 架構(gòu)不匹配
15.8 選擇你的抽象級別
15.9 規(guī)劃用戶界面
15.10 指定性模型對描述性模型
15.11 對現(xiàn)有系統(tǒng)進行建模
15.12 小結(jié)
15.13 深入閱讀
第16章 結(jié)論
16.1 挑戰(zhàn)
16.2 聚焦質(zhì)量屬性
16.3 解決問題,而不是僅僅對它們建模
16.4 使用導(dǎo)軌一樣的約束
16.5 使用標(biāo)準(zhǔn)架構(gòu)抽象
術(shù)語表
文獻
索引
第1章 概述
隨著歲月的推移,軟件系統(tǒng)無論是規(guī)模還是復(fù)雜度都在呈數(shù)量級增長。作為軟件的構(gòu)建者,這種非凡的變化帶給我們的驚嘆遠(yuǎn)甚于恐慌。設(shè)想我們采用同樣的方式讓籃球比賽不停地擴大規(guī)模,在10年內(nèi),從最初的5名球員,增加到50名球員,再到500名球員……該是多么困難。正是因為這樣的高速發(fā)展,今日之軟件系統(tǒng)無論是規(guī)模,還是復(fù)雜度,均遠(yuǎn)遠(yuǎn)超出過去構(gòu)建的任何系統(tǒng)。
軟件開發(fā)者常常陷入與復(fù)雜度和規(guī)模這些宿敵斗爭的泥沼。但正所謂“魔高一尺,道高一丈”,無論對手變得多么強大,開發(fā)者總能絕處逢生,甚至大獲全勝。他們是如何做到的?
一種答案是,軟件工程的進展已經(jīng)與軟件規(guī)模及復(fù)雜度的增長相當(dāng)。匯編語言編程(assemblylanguageprogramming)已讓位于更高級的語言及結(jié)構(gòu)化編程。在許多領(lǐng)域,過程已讓位于對象。軟件重用在過去僅僅意味著子例程(subroutine),而現(xiàn)在卻代表種類繁多的程序庫及框架。
如今,開發(fā)者與軟件復(fù)雜度之間的戰(zhàn)爭似乎陷入了僵持狀態(tài),這并非巧合。由于開發(fā)者無法平添智慧,因此轉(zhuǎn)而改良他們的武器。武器的改良給了開發(fā)者兩種選擇:是更容易解決昨日之難題,還是準(zhǔn)備與明日之?dāng)匙鲬?zhàn)?盡管我們并不比前輩開發(fā)者更加聰明,但是改良了的武器使得我們能夠構(gòu)建規(guī)模更大、復(fù)雜度更高的軟件。
軟件開發(fā)者總是善于運用一些有形的武器,例如,集成開發(fā)環(huán)境(integrateddevelopmentenvironments,IDEs)和編程語言,然而,無形的武器帶來的影響可以說更為深遠(yuǎn);氐交@球比賽的隱喻。假設(shè)教練和新手(初出茅廬的新隊員)正在觀看同一場比賽。教練所能察覺到的內(nèi)容會遠(yuǎn)遠(yuǎn)超過新手。這并非是因為教練火眼金睛,而是因為他掌握了某種無形的武器。通過建立一整套思維抽象,教練能夠透過現(xiàn)象看到本質(zhì),把對原始現(xiàn)象的感知轉(zhuǎn)換為對目前局勢簡明扼要的理解。……