領域驅動設計：軟件核心復雜性應對之道

第一部分 運用領域模型
第1章 消化知識5
1.1有效建模的要素9
1.2知識消化10
1.3持續學習11
1.4知識豐富的設計12
1.5深層模型15
第2章 交流與語言的使用16
2.1模式：UBIQUITOUS LANGUAGE16
2.2「大聲地」建模21
2.3一個團隊，一種語言22
2.4文檔和圖24
2.4.1書面設計文檔25
2.4.2完全依賴可執行代碼的情況27
2.5解釋性模型27
第3章 綁定模型和實現29
3.1模式：MODEL—DRIVEN DESIGN30
3.2建模范式和工具支持32
3.3揭示主旨：為什麼模型對用戶至關重要38
3.4模式：HANDS—ON MODELER39

第二部分 模型驅動設計的構造塊
第4章 分離領域43
4.1模式：LAYERED ARCHITECTURE43
4.1.1將各層關聯起來46
4.1.2架構框架47
4.2領域層是模型的精髓48
4.3模式：THE SMART UI「反模式」48
4.4其他分離方式50
第5章 軟件中所表示的模型51
5.1關聯52
5.2模式：ENTITY（又稱為REFERENCE OBJECT）56
5.2.1ENTITY建模59
5.2.2設計標識操作60
5.3模式：VALUE OBJECT62
5.3.1設計VALUE OBJECT64
5.3.2設計包含VALUE OBJECT的關聯67
5.4模式：SERVICE67
5.4.1SERVICE與孤立的領域層69
5.4.2粒度70
5.4.3對SERVICE的訪問70
5.5模式：MODULE（也稱為PACKAGE）71
5.5.1敏捷的MODULE72
5.5.2通過基礎設施打包時存在的隱患73
5.6建模范式75
5.6.1對象范式流行的原因76
5.6.2對象世界中的非對象77
5.6.3在混合范式中堅持使用MODEL—DRIVEN DESIGN78
第6章 領域對象的生命周期80
6.1模式：AGGREGATE81
6.2模式：FACTORY89
6.2.1選擇FACTORY及其應用位置91
6.2.2有些情況下只需使用構造函數93
6.2.3接口的設計94
6.2.4固定規則的相關邏輯應放置在哪里94
6.2.5ENTITY FACTORY與VALUEOBJECT FACTORY95
6.2.6重建已存儲的對象95
6.3模式：REPOSITORY97
6.3.1REPOSITORY的查詢101
6.3.2客戶代碼可以忽略REPOSITORY的實現，但開發人員不能忽略102
6.3.3REPOSITORY的實現103
6.3.4在框架內工作104
6.3.5REPOSITORY與FACTORY的關系104
6.4為關系數據庫設計對象106
第7章 使用語言：一個擴展的示例108
7.1貨物運輸系統簡介108
7.2隔離領域：引入應用層110
7.3將ENTITY和VALUE OBJECT區別開110
7.4設計運輸領域中的關聯112
7.5AGGREGATE邊界113
7.6選擇REPOSITORY113
7.7場景走查115
7.7.1應用程序特性舉例：更改Cargo的目的地115
7.7.2應用程序特性舉例：重復業務116
7.8對象的創建116
7.8.1Cargo的FACTORY和構造函數116
7.8.2添加Handling Event117
7.9停一下，重構：Cargo AGGREGATE的另一種設計118
7.10運輸模型中的MODULE120
7.11引入新特性：配額檢查122
7.11.1連接兩個系統123
7.11.2進一步完善模型：划分業務124
7.11.3性能優化125
7.12小結126

第三部分 通過重構來加深理解
第8章 突破131
8.1一個關於突破的故事131
8.1.1華而不實的模型132
8.1.2突破133
8.1.3更深層模型135
8.1.4冷靜決策137
8.1.5成果138
8.2機遇138
8.3關注根本138
8.4后記：越來越多的新理解139
第9章 將隱式概念轉變為顯式概念140
9.1概念挖掘140
9.1.1傾聽語言140
9.1.2檢查不足之處144
9.1.3思考矛盾之處148
9.1.4查閱書籍148
9.1.5嘗試，再嘗試150
9.2如何為那些不太明顯的概念建模150
9.2.1顯式的約束151
9.2.2將過程建模為領域對象153
9.2.3模式：SPECIFICATION154
9.2.4SPECIFICATION的應用和實現156
第10章 柔性設計168
10.1模式：INTENTION—REVEALING INTERFACES169
10.2模式：SIDE—EFFECT—FREE FUNCTION173
10.3模式：ASSERTION177
10.4模式：CONCEPTUAL CONTOUR181
10.5模式：STANDALONE CLASS184
10.6模式：CLOSURE OF OPERATION186
10.7聲明式設計188
10.8聲明式設計風格190
10.9切入問題的角度197
10.9.1分割子領域197
10.9.2盡可能利用已有的形式198
第11章 應用分析模式206
第12章 將設計模式應用於模型217
12.1模式：STRATEGY（也稱為POLICY）218
12.2模式：COMPOSITE221
12.3為什麼沒有介紹FLYWEIGHT226
第13章 通過重構得到更深層的理解227
13.1開始重構227
13.2探索團隊227
13.3借鑒先前的經驗228
13.4針對開發人員的設計229
13.5重構的時機229
13.6危機就是機遇230

第四部分 戰略設計
第14章 保持模型的完整性233
14.1模式：BOUNDED CONTEXT235
14.2模式：CONTINUOUS INTEGRATION239
14.3模式：CONTEXT MAP241
14.3.1測試CONTEXT的邊界247
14.3.2CONTEXT MAP的組織和文檔化247
14.4BOUNDED CONTEXT之間的關系248
14.5模式：SHARED KERNEL248
14.6模式：CUSTOMER／SUPPLIER DEVELOPMENT TEAM250
14.7模式：CONFORMIST253
14.8模式：ANTICORRUPTION LAYER255
14.8.1設計ANTICORRUPTION LAYER的接口256
14.8.2實現ANTICORRUPTION LAYER256
14.8.3一個關於防御的故事259
14.9模式：SEPARATE WAY260
14.10模式：OPENHOST SERVICE261
14.11模式：PUBLISHED LANGUAGE262
14.12「大象」的統一264
14.13選擇你的模型上下文策略267
14.13.1團隊決策或更高層決策268
14.13.2置身上下文中268
14.13.3轉換邊界268
14.13.4接受那些我們無法更改的事物：描述外部系統269
14.13.5與外部系統的關系269
14.13.6設計中的系統270
14.13.7用不同模型滿足特殊需要270
14.13.8部署271
14.13.9權衡271
14.13.10當項目正在進行時272
14.14轉換272
14.14.1合並CONTEXT：SEPARATE WAY→SHARED KERNEL273
14.14.2合並CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION274
14.14.3逐步淘汰遺留系統275
14.14.4OPEN HOST SERVICE→PUBLISHED LANGUAGE276
第15章 精煉277
15.1模式：CORE DOMAIN278
15.1.1選擇核心280
15.1.2工作的分配280
15.2精煉的逐步提升281
15.3模式：GENERIC SUBDOMAIN282
15.3.1通用不等於可重用286
15.3.2項目風險管理287
15.4模式：DOMAIN VISION STATEMENT287
15.5模式：HIGHLIGHTED CORE289
15.5.1精煉文檔289
15.5.2標明CORE290
15.5.3把精煉文檔作為過程工具291
15.6模式：COHESIVE MECHANISM292
15.6.1GENERIC SUBDOMAIN與COHESIVE MECHANISM的比較293
15.6.2MECHANISM是COREDOMAIN一部分294
15.7通過精煉得到聲明式風格294
15.8模式：SEGREGATED CORE295
15.8.1創建SEGREGATED CORE的代價296
15.8.2不斷發展演變的團隊決策296
15.9模式：ABSTRACT CORE301
15.10深層模型精煉302
15.11選擇重構目標302
第16章 大型結構303
16.1模式：EVOLVING ORDER306
16.2模式：SYSTEM METAPHOR308
16.3模式：RESPONSIBI LITYLAYER309
16.4模式：KNOWLEDGE LEVEL321
16.5模式：PLUGGABLE COMPONENT FRAMEWORK328
16.6結構應該有一種什麼樣的約束332
16.7通過重構得到更適當的結構333
16.7.1最小化333
16.7.2溝通和自律334
16.7.3通過重構得到柔性設計334
16.7.4通過精煉可以減輕負擔334
第17章 領域驅動設計的綜合運用336
17.1把大型結構與BOUNDED CONTEXT結合起來使用336
17.2將大型結構與精煉結合起來使用339
17.3首先評估339
17.4由誰制定策略341
17.4.1從應用程序開發自動得出的結構341
17.4.2以客戶為中心的架構團隊341
17.5制定戰略設計決策的6個要點342
17.5.1技術框架同樣如此344
17.5.2注意總體規划345
結束語
附錄351
術語表354
參考文獻357
圖片說明359
索引360