本書描述了一種恰如其分的架構設計方法。作者建議根據項目面臨的風險來調整架構設計的成本，并從多個視角闡述了軟件架構的建模過程和方法，包括用例模型、概念模型、域模型、設計模型和代碼模型等。本書不僅介紹方法，而且還對方法和概念進行了歸類和闡述，將軟件架構設計融入開發實踐中，與敏捷開發方法有機地結合在一起，適合普通程序員閱讀。
George Fairbanks在卡內基·梅隆大學獲得軟件工程專業博士學位，現任Rhino Research公司董事長。Rhino Research是一家專門提供軟件開發培訓及咨詢的公司，總部設在美國科羅拉多州博爾德市。
張逸是ThoughtWorks高級咨詢師，程 序員。InfoQ中文站編輯。著譯作包括《軟件設計精要與模式》《WCF服務編程》《Java設計模式》以及評注版《重構：改善既有代碼的設計》。目前居住于成都。
倪健是eBaoTech應用架構師，程序員。著作包括《簡單之美：軟件開發實踐者的思考》《IT項目管理那些事兒》(與人合著)。目前居住于上海。
第1章 概述
1.1 分治、知識與抽象
1.2 軟件架構的三個案例
1.3 反思
1.4 視角轉換
1.5 架構師構建架構
1.6 風險驅動的軟件架構
1.7 敏捷開發者的架構
1.8 關于本書
第2章 軟件架構
2.1 何為軟件架構？
2.2 軟件架構為何重要
2.3 架構何時重要？
2.4 推定架構
2.5 如何運用軟件架構？
2.6 架構無關的設計
2.7 專注架構的設計
2.8 提升架構的設計
2.9 大型組織中的架構
2.10 結論
2.11 延伸閱讀
第3章 風險驅動模型
3.1 風險驅動模型是什么？
3.2 你現在采用風險驅動了嗎？
3.3 風險
3.4 技術
3.5 選擇技術的指導原則
3.6 何時停止
3.7 計劃式設計與演進式設計
3.8 軟件開發過程
3.9 理解過程變化
3.10 風險驅動模型與軟件開發過程
3.11 應用于敏捷過程
3.12 風險與架構重構
3.13 風險驅動模型的替代方案
3.14 結論
3.15 延伸閱讀
第4章 實例：家庭媒體播放器
4.1 團隊溝通
4.2 COTS組件的集成
4.3 元數據一致性
4.4 結論
第5章 建模建議
5.1 專注于風險
5.2 理解你的架構
5.3 傳播架構技能
5.4 作出合理的架構決策
5.5 避免預先大量設計
5.6 避免自頂向下設計
5.7 余下的挑戰
5.8 特性和風險：一個故事
第6章 工程師使用模型
6.1 規模與復雜度需要抽象
6.2 抽象提供洞察力和解決手段
6.3 分析系統質量
6.4 模型忽略細節
6.5 模型能夠增強推理
6.6 提問在前，建模在后
6.7 小結
6.8 延伸閱讀
第7章 軟件架構的概念模型
7.1 規范化模型結構
7.2 領域模型、設計模型和代碼模型
7.3 指定與細化關系
7.4 主模型的視圖
7.5 組織模型的其他方式
7.6 業務建模
7.7 UML的用法
7.8 小結
7.9 延伸閱讀
第8章 領域模型
8.1 領域與架構的關系
8.2 信息模型
8.3 導航和不變量
8.4 快照
8.5 功能場景
8.6 小結
8.7 延伸閱讀
第9章 設計模型
9.1 設計模型
9.2 邊界模型
9.3 內部模型
9.4 質量屬性
9.5 Yinzer系統的設計之旅
9.6 視圖類型
9.7 動態架構模型
9.8 架構描述語言
9.9 小結
9.10 深入閱讀
第10章 代碼模型
10.1 模型-代碼差異
10.2 一致性管理
10.3 架構明顯的編碼風格
10.4 在代碼中表達設計意圖
10.5 模型嵌入代碼原理
10.6 表達什么
10.7 在代碼中表達設計意圖的模式
10.8 電子郵件處理系統預演
10.9 小結
第11章 封裝和分割
11.1 多層級故事
11.2 層級和分割
11.3 分解策略
11.4 有效封裝
11.5 創建封裝接口
11.6 小結
11.7 深入閱讀
第12章 模型元素
12.1 和部署相關的元素
12.2 組件
12.3 組件裝配
12.4 連接器
12.5 設計決策
12.6 功能場景
12.7 (不變量(約束)
12.8 模塊
12.9 端口
12.10 質量屬性
12.11 質量屬性場景
12.12 職責
12.13 權衡
12.14 小結
第13章 模型關系
13.1 投影(視圖)關系
13.2 分割關系
13.3 組合關系
13.4 分類關系
13.5 泛化關系
13.6 指定關系
13.7 細化關系
13.8 綁定關系
13.9 依賴關系
13.10 使用關系
13.11 小結
13.12 深入閱讀
第14章 架構風格
14.1 優勢
14.2 柏拉圖式風格對體驗式風格
14.3 約束和以架構為中心的設計
14.4 模式對風格
14.5 風格目錄
14.6 分層風格
14.7 大泥球風格
14.8 管道-過濾器風格
14.9 批量順序處理風格
14.10 以模型為中心的風格
14.11 分發-訂閱風格
14.12 客戶端-服務器風格和多層
14.13 對等風格
14.14 map-reduce風格
14.15 鏡像，支架和農場風格
14.16 小結
14.17 深入閱讀
第15章 使用架構模型
15.1 理想的模型特性
15.2 和視圖一起工作
15.3 改善視圖質量
15.4 提高圖的質量
15.5 測試和證明
15.6 分析架構模型
15.7 架構不匹配
15.8 選擇你的抽象級別
15.9 規劃用戶界面
15.10 指定性模型對描述性模型
15.11 對現有系統進行建模
15.12 小結
15.13 深入閱讀
第16章 結論
16.1 挑戰
16.2 聚焦質量屬性
16.3 解決問題，而不是僅僅對它們建模
16.4 使用導軌一樣的約束
16.5 使用標準架構抽象
術語表
文獻
索引
第1章概述
隨著歲月的推移，軟件系統無論是規模還是復雜度都在呈數量級增長。作為軟件的構建者，這種非凡的變化帶給我們的驚嘆遠甚于恐慌。設想我們采用同樣的方式讓籃球比賽不停地擴大規模，在10年內，從最初的5名球員，增加到50名球員，再到500名球員……該是多么困難。正是因為這樣的高速發展，今日之軟件系統無論是規模，還是復雜度，均遠遠超出過去構建的任何系統。
軟件開發者常常陷入與復雜度和規模這些宿敵斗爭的泥沼。但正所謂"魔高一尺，道高一丈"，無論對手變得多么強大，開發者總能絕處逢生，甚至大獲全勝。他們是如何做到的?
一種答案是，軟件工程的進展已經與軟件規模及復雜度的增長相當。匯編語言編程(assembly language programming)已讓位于更高級的語言及結構化編程。在許多領域，過程已讓位于對象。軟件重用在過去僅僅意味著子例程(subroutine)，而現在卻代表種類繁多的程序庫及框架。
如今，開發者與軟件復雜度之間的戰爭似乎陷入了僵持狀態，這并非巧合。由于開發者無法平添智慧，因此轉而改良他們的武器。武器的改良給了開發者兩種選擇：是更容易解決昨日之難題，還是準備與明日之敵作戰?盡管我們并不比前輩開發者更加聰明，但是改良了的武器使得我們能夠構建規模更大、復雜度更高的軟件。
軟件開發者總是善于運用一些有形的武器，例如，集成開發環境(integrateddevelopment environments，IDEs)和編程語言，然而，無形的武器帶來的影響可以說更為深遠。回到籃球比賽的隱喻。假設教練和新手(初出茅廬的新隊員)正在觀看同一場比賽。教練所能察覺到的內容會遠遠超過新手。這并非是因為教練火眼金睛，而是因為他掌握了某種無形的武器。通過建立一整套思維抽象，教練能夠透過現象看到本質，把對原始現象的感知轉換為對目前局勢簡明扼要的理解。……
物流也快，不錯
發貨快，沒有塑封，這次買了幾本用紙箱郵來的，非常好！
非常不錯的書
講的還可以
質量還不錯
好評哈哈哈
不錯 正品
還沒看，希望有幫助
就獎勵開開心心
這個商品不錯
挺好的一本書
還不錯哦，好評！
還沒看呢，還行吧
書是好書，質量也還可以，就是當當的服務實在是太差了啊，發貨速度慢的要死，然后物流都是交給三方的，簽收的時候派了一個不懂怎么使用pos機的人，卡刷了，沒有交易單，書的包裝簡直太環保了，直接裸奔，連基本的塑料皮都沒有。
快遞員態度很差，可以一星都不給嗎
看過在評論
廢話太多了，容易抓不住重點，翻譯也一般
適合新手。
書經典，送貨快遞成了慢遞，北京發出，三天后才到深圳。
感覺像盜版書，談架構的，沒有一個架構圖，或者如何畫架構圖
翻譯應該是沒有比這個更爛的，讀起來感覺書中的翻譯就是挨句用翻譯工具翻譯的。兩句翻譯之間的內容可以來個大角度內容轉折。這種書看多了語言溝通會出現很嚴重的障礙。
偏理論些，不過感覺還好了，估計要好長一段時間來消化。。。。。
書是好書， 粗粗讀了前四章， 對架構設計做了很好的思考和總結，值得一讀。 不過書的封面顯得舊了一些。
很不錯的一本書，里面講的挺好的，作者經驗很豐富。
過猶不及，不能為設計而設計，為架構而架構，正是“恰如其分”這個詞讓我決定買它看看
好書。值得仔細閱讀的技術書。都是經過多次淘選的。
書送到手之后，包括書頁之類的有被人試用過的痕跡，懷疑是二手書
看了兩章，看覺很抽象，我還是個初級工程師，但還是很想了解軟件架構。
翻譯的太差勁了，英文的冗長句子幾乎就是原封不動的翻譯出來的，本來原版可能是本好書，經這么一翻譯簡直就是。。。看的人想睡覺。
本書是一本介紹軟件架構不可多得的好書，內容詳實，結構合理，值得一讀。
本書介紹了設計軟件架構的方方面面，如何設計一個系統的架構，強調恰如其分而不是過度的設計，主張根據需要不斷的演進架構，而不是一開始就設計一個面面俱到的軟件架構，這是不現實的。
