本書描述了一種恰如其分的架構(gòu)設(shè)計方法。作者建議根據(jù)項目面臨的風險來調(diào)整架構(gòu)設(shè)計的成本,并從多個視角闡述了軟件架構(gòu)的建模過程和方法,包括用例模型、概念模型、域模型、設(shè)計模型和代碼模型等。本書不僅介紹方法,而且還對方法和概念進行了歸類和闡述,將軟件架構(gòu)設(shè)計融入開發(fā)實踐中,與敏捷開發(fā)方法有機地結(jié)合在一起,適合普通程序員閱讀。
《恰如其分的軟件架構(gòu)》的作者在探討比較多種架構(gòu)風格的差異和利弊的基礎(chǔ)上,結(jié)合自己的工作經(jīng)驗,提煉出通過風險驅(qū)動的軟件架構(gòu)設(shè)計方法,旨在彌補敏捷開發(fā)方法在實際工程應(yīng)用中的不足。本書將理論與實踐相結(jié)合,不僅條理清晰地描述了設(shè)計軟件架設(shè)的各種思路,而且詳細介紹了經(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 風險驅(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 風險驅(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章 風險驅(qū)動模型
3.1 風險驅(qū)動模型是什么?
3.2 你現(xiàn)在采用風險驅(qū)動了嗎?
3.3 風險
3.4 技術(shù)
3.5 選擇技術(shù)的指導(dǎo)原則
3.6 何時停止
3.7 計劃式設(shè)計與演進式設(shè)計
3.8 軟件開發(fā)過程
3.9 理解過程變化
3.10 風險驅(qū)動模型與軟件開發(fā)過程
3.11 應(yīng)用于敏捷過程
3.12 風險與架構(gòu)重構(gòu)
3.13 風險驅(qū)動模型的替代方案
3.14 結(jié)論
3.15 延伸閱讀
第4章 實例:家庭媒體播放器
4.1 團隊溝通
4.2 COTS組件的集成
4.3 元數(shù)據(jù)一致性
4.4 結(jié)論
第5章 建模建議
5.1 專注于風險
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 特性和風險:一個故事
第6章 工程師使用模型
6.1 規(guī)模與復(fù)雜度需要抽象
6.2 抽象提供洞察力和解決手段
6.3 分析系統(tǒng)質(zhì)量
6.4 模型忽略細節(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 指定與細化關(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)明顯的編碼風格
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 職責
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 細化關(guān)系
13.8 綁定關(guān)系
13.9 依賴關(guān)系
13.10 使用關(guān)系
13.11 小結(jié)
13.12 深入閱讀
第14章 架構(gòu)風格
14.1 優(yōu)勢
14.2 柏拉圖式風格對體驗式風格
14.3 約束和以架構(gòu)為中心的設(shè)計
14.4 模式對風格
14.5 風格目錄
14.6 分層風格
14.7 大泥球風格
14.8 管道-過濾器風格
14.9 批量順序處理風格
14.10 以模型為中心的風格
14.11 分發(fā)-訂閱風格
14.12 客戶端-服務(wù)器風格和多層
14.13 對等風格
14.14 map-reduce風格
14.15 鏡像,支架和農(nó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 使用標準架構(gòu)抽象
術(shù)語表
文獻
索引
第1章 概述
隨著歲月的推移,軟件系統(tǒng)無論是規(guī)模還是復(fù)雜度都在呈數(shù)量級增長。作為軟件的構(gòu)建者,這種非凡的變化帶給我們的驚嘆遠甚于恐慌。設(shè)想我們采用同樣的方式讓籃球比賽不停地擴大規(guī)模,在10年內(nèi),從最初的5名球員,增加到50名球員,再到500名球員……該是多么困難。正是因為這樣的高速發(fā)展,今日之軟件系統(tǒng)無論是規(guī)模,還是復(fù)雜度,均遠遠超出過去構(gòu)建的任何系統(tǒng)。
軟件開發(fā)者常常陷入與復(fù)雜度和規(guī)模這些宿敵斗爭的泥沼。但正所謂“魔高一尺,道高一丈”,無論對手變得多么強大,開發(fā)者總能絕處逢生,甚至大獲全勝。他們是如何做到的?
一種答案是,軟件工程的進展已經(jīng)與軟件規(guī)模及復(fù)雜度的增長相當。匯編語言編程(assemblylanguageprogramming)已讓位于更高級的語言及結(jié)構(gòu)化編程。在許多領(lǐng)域,過程已讓位于對象。軟件重用在過去僅僅意味著子例程(subroutine),而現(xiàn)在卻代表種類繁多的程序庫及框架。
如今,開發(fā)者與軟件復(fù)雜度之間的戰(zhàn)爭似乎陷入了僵持狀態(tài),這并非巧合。由于開發(fā)者無法平添智慧,因此轉(zhuǎn)而改良他們的武器。武器的改良給了開發(fā)者兩種選擇:是更容易解決昨日之難題,還是準備與明日之敵作戰(zhàn)?盡管我們并不比前輩開發(fā)者更加聰明,但是改良了的武器使得我們能夠構(gòu)建規(guī)模更大、復(fù)雜度更高的軟件。
軟件開發(fā)者總是善于運用一些有形的武器,例如,集成開發(fā)環(huán)境(integrateddevelopmentenvironments,IDEs)和編程語言,然而,無形的武器帶來的影響可以說更為深遠;氐交@球比賽的隱喻。假設(shè)教練和新手(初出茅廬的新隊員)正在觀看同一場比賽。教練所能察覺到的內(nèi)容會遠遠超過新手。這并非是因為教練火眼金睛,而是因為他掌握了某種無形的武器。通過建立一整套思維抽象,教練能夠透過現(xiàn)象看到本質(zhì),把對原始現(xiàn)象的感知轉(zhuǎn)換為對目前局勢簡明扼要的理解。……