在軟件開發(fā)流程中，為了盡可能快地響應各種變化，理應把結(jié)構(gòu)漸進改變作為設計的首要原則�！堆葸M式架構(gòu)》詳盡闡述了演進式架構(gòu)的必要性、構(gòu)建方法以及需要注意的問題。各章結(jié)合案例分別討論了軟件架構(gòu)、適應度函數(shù)、開展增量變更、架構(gòu)耦合、演進式數(shù)據(jù)、構(gòu)建可演進的架構(gòu)、演進式架構(gòu)的陷阱和反模式，以及實踐演進式架構(gòu)。
《演進式架構(gòu)》由IT行業(yè)領導企業(yè)ThoughtWorks的CTO和架構(gòu)專家聯(lián)合執(zhí)筆，詳盡介紹了演進式架構(gòu)的必要性以及如何在具體的軟件開發(fā)流程中實現(xiàn)演進式架構(gòu)，涵蓋了適應度函數(shù)、增量變更、架構(gòu)耦合、演進式數(shù)據(jù)、構(gòu)架可演進的架構(gòu)、實踐演進式架構(gòu)等內(nèi)容。
1.敏捷之父、暢銷書《重構(gòu) 改善既有代碼的設計》作者、世界知名軟件開發(fā)大師馬丁·福勒傾情作序推薦；
2.《演進式架構(gòu)》為O'Reilly系列叢書，“動物書”多年來已經(jīng)成為廣大程序員解決問題的實用指南；
3.作者和譯者均為業(yè)內(nèi)資-深架構(gòu)專家，書本內(nèi)容為他們多年來的實戰(zhàn)經(jīng)驗，讓讀者在軟件開發(fā)時少走彎路；
4.《演進式架構(gòu)》著眼于理論、立足于實踐，每一個章節(jié)都有豐富的案例研究，讓讀者在閱讀此書后可以充分了解并掌握演進式架構(gòu)；
尼爾·福特（Neal Ford）是ThoughtWorks軟件架構(gòu)師、Meme Wrangler，曾任DSW集團CTO,是國際公認的軟件開發(fā)與交付專家。
麗貝卡·帕森斯（Rebecca Parsons）是ThoughtWorks CTO，在大規(guī)模分布式對象應用開發(fā)和系統(tǒng)集成方面擁有豐富經(jīng)驗。
帕特里卡·柯（Patrick Kua）是數(shù)字銀行N26科學家，曾任ThoughtWorks主任咨詢師和技術(shù)主管，在敏捷和精益開發(fā)方面擁有豐富經(jīng)驗。
版權(quán)聲明 ii
O'Reilly Media， Inc．介紹 iv
序 ix
前言 xi
第 1章 軟件架構(gòu) 1
1．1 演進式架構(gòu) 2
1．1．1 一切都在變化，如何才能長期規(guī)劃 3
1．1．2 完成架構(gòu)構(gòu)建后，如何防止它逐漸退化 4
1．2 增量變更 5
1．3 引導性變更 6
1．4 多個架構(gòu)維度 6
1．5 康威定律 8
1．6 為何演進 10
1．7 小結(jié) 11
第 2章 適應度函數(shù) 13
2．1 什么是適應度函數(shù) 15
2．2 適應度函數(shù)分類 16
2．2．1 原子適應度函數(shù)與整體適應度函數(shù) 16
2．2．2 觸發(fā)式適應度函數(shù)與持續(xù)式適應度函數(shù) 16
2．2．3 靜態(tài)適應度函數(shù)與動態(tài)適應度函數(shù) 17
2．2．4 自動適應度函數(shù)與手動適應度函數(shù) 17
2．2．5 臨時適應度函數(shù) 18
2．2．6 預設式高于應急式 18
2．2．7 針對特定領域的適應度函數(shù) 18
2．3 盡早確定適應度函數(shù) 18
2．4 審查適應度函數(shù) 19
第3章 實施增量變更 21
3．1 構(gòu)件 24
3．1．1 可測試性 25
3．1．2 部署流水線 26
3．1．3 組合不同類型的適應度函數(shù) 30
3．1．4 案例研究：在每天部署60次的情況下重建架構(gòu) 31
3．1．5 目標沖突 33
3．1．6 案例研究：為PenultimateWidgets的發(fā)票服務添加適應度函數(shù) 33
3．2 假設驅(qū)動開發(fā)和數(shù)據(jù)驅(qū)動開發(fā) 36
3．3 案例研究：移植什么 37
第4章 架構(gòu)耦合 39
4．1 模塊化 39
4．2 架構(gòu)的量子和粒度 40
4．3 不同類型架構(gòu)的演進能力 42
4．3．1 大泥團架構(gòu) 42
4．3．2 單體架構(gòu) 44
4．3．3 事件驅(qū)動架構(gòu) 49
4．3．4 服務導向架構(gòu) 53
4．3．5 “無服務”架構(gòu) 62
4．4 控制架構(gòu)量子大小 63
4．5 案例分析：防止組件循環(huán)依賴 64
第5章 演進式數(shù)據(jù) 67
5．1 演進式數(shù)據(jù)庫設計 67
5．1．1 數(shù)據(jù)庫模式演進 67
5．1．2 共享數(shù)據(jù)庫集成 69
5．2 不當?shù)臄?shù)據(jù)耦合 73
5．2．1 二階段提交事務 74
5．2．2 數(shù)據(jù)的年齡和質(zhì)量 75
5．3 案例研究：PenultimateWidgets的路由演進 76
第6章 構(gòu)建可演進的架構(gòu) 79
6．1 演進機制 79
6．1．1 識別受演進影響的架構(gòu)維度 79
6．1．2 為每個維度定義適應度函數(shù) 80
6．1．3 使用部署流水線自動化適應度函數(shù) 80
6．2 全新的項目 80
6．3 改良現(xiàn)有架構(gòu) 81
6．3．1 適當?shù)鸟詈虾蛢?nèi)聚 81
6．3．2 工程實踐 81
6．3．3 適應度函數(shù) 82
6．3．4 關(guān)于商業(yè)成品軟件 82
6．4 架構(gòu)遷移 83
6．4．1 遷移步驟 84
6．4．2 演進模塊間的交互 86
6．5 演進式架構(gòu)構(gòu)建指南 89
6．5．1 去除不必要的可變性 89
6．5．2 讓決策可逆 91
6．5．3 演進優(yōu)于預測 91
6．5．4 構(gòu)建防腐層 92
6．5．5 案例分析：服務模板 93
6．5．6 構(gòu)建可犧牲架構(gòu) 94
6．5．7 應對外部變化 95
6．5．8 更新庫與更新框架 97
6．5．9 持續(xù)交付優(yōu)于快照 97
6．5．10 服務內(nèi)部版本化 98
6．6 案例分析：PenultimateWidgets的評分服務演進 99
第7章 演進式架構(gòu)的陷阱和反模式 103
7．1 技術(shù)架構(gòu) 103
7．1．1 反模式：供應商為王 103
7．1．2 陷阱：抽象泄漏 104
7．1．3 反模式：最后10%的陷阱 107
7．1．4 反模式：代碼復用和濫用 108
7．1．5 案例研究：PenultimateWidgets中的復用 109
7．1．6 陷阱：簡歷驅(qū)動開發(fā) 110
7．2 增量變更 111
7．2．1 反模式：管理不當 111
7．2．2 案例研究：PenultimateWidgets的“金發(fā)姑娘”管理 112
7．2．3 陷阱：發(fā)布過慢 113
7．3 業(yè)務問題 114
7．3．1 陷阱：產(chǎn)品定制 114
7．3．2 反模式：報表 115
7．3．3 陷阱：規(guī)劃視野 116
第8章 實踐演進式架構(gòu) 119
8．1 組織因素 119
8．1．1 全功能團隊 119
8．1．2 圍繞業(yè)務能力組織團隊 121
8．1．3 產(chǎn)品高于項目 121
8．1．4 應對外部變化 122
8．1．5 團隊成員間的連接數(shù) 123
8．2 團隊的耦合特征 124
8．2．1 文化 124
8．2．2 試驗文化 125
8．3 首席財務官和預算 126
8．4 構(gòu)建企業(yè)適應度函數(shù) 128
8．5 從何開始 129
8．5．1 容易實現(xiàn)的目標 129
8．5．2 最高價值優(yōu)先 129
8．5．3 測試 129
8．5．4 基礎設施 130
8．5．5 PenultimateWidgets的企業(yè)架構(gòu)師 131
8．6 演進式架構(gòu)的未來 131
8．6．1 基于AI的適應度函數(shù) 132
8．6．2 生成式測試 132
8．7 為什么（不）呢 132
8．7．1 公司為何決定構(gòu)建演進式架構(gòu) 132
8．7．2 案例分析：PenultimateWidgets選擇性伸展 134
8．7．3 企業(yè)為何選擇不構(gòu)建演進式架構(gòu) 135
8．7．4 說服他人 136
8．7．5 案例分析：“咨詢?nèi)岬馈薄?36
8．8 商業(yè)案例 136
8．8．1 未來已來…… 136
8．8．2 沒有后顧之憂地快速前行 137
8．8．3 風險更低 137
8．8．4 新能力 137
8．9 構(gòu)建演進式架構(gòu) 137
關(guān)于作者 139
封面介紹 140
書單推薦
