掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
領域驅動設計 軟件核心復雜性應對之道 修訂版 版權信息
- ISBN：9787115376756
- 條形碼：9787115376756 ; 978-7-115-37675-6
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
領域驅動設計 軟件核心復雜性應對之道 修訂版 本書特色
·“領域驅動設計之父”經典著作 ·眾多聲名顯赫軟件大師鼎力推薦 ·凝聚領域建模專家數十年的實戰經驗 ·深度剖析構建高質量復雜系統的核心技術 領域模型使開發人員可以表達豐富的軟件功能需求，由此實現的軟件可以滿足用戶真正的需要，因此被公認為是軟件設計的關鍵所在，其重要性顯而易見。但講述如何將領域模型用于軟件開發過程的杰出的實用資料卻不多見。本書正是這一領域聲名顯赫的作品，受到眾多業界大師的贊美和推介，廣受讀者好評。要通過創建領域模型來加速復雜的軟件開發，就需要利用大量實踐和標準模式在開發團隊中形成統一的交流語言；不但要重構代碼，而且要重構代碼底層的模型；同時采取反復迭代的敏捷開發方法，深入理解領域特點，促進領域專家與程序員的良好溝通。針對這些內容，本書結合真實項目，系統地介紹了領域驅動開發的目標、意義和方法，充分討論了復雜系統的建模與設計問題。本書將指導面向對象開發人員、系統分析人員和設計人員合理地組織工作，各有側重、彼此協作，有條不紊地進行復雜系統的開發，幫助他們建立豐富而實用的領域模型，并由此創建長期適用的優質軟件。
領域驅動設計 軟件核心復雜性應對之道 修訂版 內容簡介
本書是領域驅動設計方面的經典之作，修訂版更是對之前出版的中文版進行了全面的修訂和完善。 全書圍繞著設計和開發實踐，結合若干真實的項目案例，向讀者闡述如何在真實的軟件開發中應用領域驅動設計。書中給出了領域驅動設計的系統化方法，并將人們普遍接受的一些實踐綜合到一起，融入了作者的見解和經驗，展現了一些可擴展的設計新實踐、已驗證過的技術以及便于應對復雜領域的軟件項目開發的基本原則。
領域驅動設計 軟件核心復雜性應對之道 修訂版 目錄
目錄
第 一部分 運用領域模型
第 1章 消化知識 5
1．1 有效建模的要素 9
1．2 知識消化 10
1．3 持續學習 11
1．4 知識豐富的設計 12
1．5 深層模型 15
第 2章 交流與語言的使用 16
2．1 模式：UBIQUITOUS LANGUAGE 16
2．2 “大聲地”建?！?1
2．3 一個團隊，一種語言 22
2．4 文檔和圖 24
2．4．1 書面設計文檔 25
2．4．2 完全依賴可執行代碼的情況 27
2．5 解釋性模型 27
第3章 綁定模型和實現 29
3．1 模式：MODEL-DRIVEN DESIGN 30
3．2 建模范式和工具支持 32
3．3 揭示主旨：為什么模型對用戶到關重要 38
3．4 模式：HANDS-ON MODELER 39
第 二部分 模型驅動設計的構造塊
第4章 分離領域 43
4．1 模式：LAYERED ARCHITECTURE 43
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．1 ENTITY建模 59
5．2．2 設計標識操作 60
5．3 模式：VALUE OBJECT 62
5．3．1 設計VALUE OBJECT 64
5．3．2 設計包含VALUE OBJECT的關聯 67
5．4 模式：SERVICE 67
5．4．1 SERVICE與孤立的領域層 69
5．4．2 粒度 70
5．4．3 對SERVICE的訪問 70
5．5 模式：ＭODULE（也稱為PACKAGE） 71
5．5．1 敏捷的MODULE 72
5．5．2 通過基礎設施打包時存在的隱患 73
5．6 建模范式 75
5．6．1 對象范式流行的原因 76
5．6．2 對象世界中的非對象 77
5．6．3 在混合范式中堅持使用MODEL-DRIVEN DESIGN 78
第6章 領域對象的生命周期 80
6．1 模式：AGGREGATE 81
6．2 模式：FACTORY 89
6．2．1 選擇FACTORY及其應用位置 91
6．2．2 有些情況下只需使用構造函數 93
6．2．3 接口的設計 94
6．2．4 固定規則的相關邏輯應放置在哪里 94
6．2．5 ENTITY FACTORY與VALUE OBJECT FACTORY 95
6．2．6 重建已存儲的對象 95
6．3 模式：REPOSITORY 97
6．3．1 REPOSITORY的查詢 101
6．3．2 客戶代碼可以忽略REPOSITORY的實現，但開發人員不能忽略 102
6．3．3 REPOSITORY的實現 103
6．3．4 在框架內工作 104
6．3．5 REPOSITORY與FACTORY的關系 104
6．4 為關系數據庫設計對象 106
第7章 使用語言：一個擴展的示例 108
7．1 貨物運輸系統簡介 108
7．2 隔離領域：引入應用層 110
7．3 將ENTITY和VALUE OBJECT區別開 110
7．4 設計運輸領域中的關聯 112
7．5 AGGREGATE邊界 113
7．6 選擇REPOSITORY 113
7．7 場景走查 115
7．7．1 應用程序特性舉例：更改Cargo的目的地 115
7．7．2 應用程序特性舉例：重復業務 116
7．8 對象的創建 116
7．8．1 Cargo的FACTORY和構造函數 116
7．8．2 添加Handling Event 117
7．9 停一下，重構：Cargo AGGREGATE 的另一種設計 118
7．10 運輸模型中的ＭODULE 120
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 如何為那些不太明顯的概念建?！?50
9．2．1 顯式的約束 151
9．2．2 將過程建模為領域對象 153
9．2．3 模式：SPECIFICATION 154
9．2．4 SPECIFICATION的應用和實現 156
第 10章 柔 性 設 計 168
10．1 模式：INTENTION-REVEALING
INTERFACES 169
10．2 模式：SIDE-EFFECT-FREE FUNCTION 173
10．3 模式：ASSERTION 177
10．4 模式：CONCEPTUAL CONTOUR 181
10．5 模式：STANDALONE CLASS 184
10．6 模式：CLOSURE OF OPERATION 186
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 模式：COMPOSITE 221
12．3 為什么沒有介紹FLYWEIGHT 226
第 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 CONTEXT 235
14．2 模式：CONTINUOUS INTEGRATION 239
14．3 模式：CONTEXT MAP 241
14．3．1 測試CONTEXT的邊界 247
14．3．2 CONTEXT MAP的組織和文檔化 247
14．4 BOUNDED CONTEXT之間的關系 248
14．5 模式：SHARED KERNEL 248
14．6 模式：CUSTOMER/SUPPLIER DEVELOPMENT TEAM 250
14．7 模式：CONFORMIST 253
14．8 模式：ANTICORRUPTION LAYER 255
14．8．1 設計ANTICORRUPTION LAYER的接口 256
14．8．2 實現ANTICORRUPTION LAYER 256
14．8．3 一個關于防御的故事 259
14．9 模式：SEPARATE WAY 260
14．10 模式：OPEN HOST SERVICE 261
14．11 模式：PUBLISHED LANGUAGE 262
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 KERNEL 273
14．14．2 合并CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION 274
14．14．3 逐步淘汰遺留系統 275
14．14．4 OPEN HOST SERVICE→PUBLISHED LANGUAGE 276
第 15章 精煉 277
15．1 模式：CORE DOMAIN 278
15．1．1 選擇核心 280
15．1．2 工作的分配 280
15．2 精煉的逐步提升 281
15．3 模式：GENERIC SUBDOMAIN 282
15．3．1 通用不等于可重用 286
15．3．2 項目風險管理 287
15．4 模式：DOMAIN VISION STATEMENT 287
15．5 模式：HIGHLIGHTED CORE 289
15．5．1 精煉文檔 289
15．5．2 標明CORE 290
15．5．3 把精煉文檔作為過程工具 291
15．6 模式：COHESIVE MECHANISM 292
15．6．1 GENERIC SUBDOMAIN與COHESIVE MECHANISM的比較 293
15．6．2 MECHANISM是CORE DOMAIN一部分 294
15．7 通過精煉得到聲明式風格 294
15．8 模式：SEGREGATED CORE 295
15．8．1 創建SEGREGATED CORE的代價 296
15．8．2 不斷發展演變的團隊決策 296
15．9 模式：ABSTRACT CORE 301
15．10 深層模型精煉 302
15．11 選擇重構目標 302
第 16章 大型結構 303
16．1 模式：EVOLVING ORDER 306
16．2 模式：SYSTEM METAPHOR 308
16．3 模式：RESPONSIBILITY LAYER 309
16．4 模式：KNOWLEDGE LEVEL 321
16．5 模式：PLUGGABLE COMPONENT FRAMEWORK 328
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
第 一部分 運用領域模型
第 1章 消化知識 5
1．1 有效建模的要素 9
1．2 知識消化 10
1．3 持續學習 11
1．4 知識豐富的設計 12
1．5 深層模型 15
第 2章 交流與語言的使用 16
2．1 模式：UBIQUITOUS LANGUAGE 16
2．2 “大聲地”建?！?1
2．3 一個團隊，一種語言 22
2．4 文檔和圖 24
2．4．1 書面設計文檔 25
2．4．2 完全依賴可執行代碼的情況 27
2．5 解釋性模型 27
第3章 綁定模型和實現 29
3．1 模式：MODEL-DRIVEN DESIGN 30
3．2 建模范式和工具支持 32
3．3 揭示主旨：為什么模型對用戶到關重要 38
3．4 模式：HANDS-ON MODELER 39
第 二部分 模型驅動設計的構造塊
第4章 分離領域 43
4．1 模式：LAYERED ARCHITECTURE 43
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．1 ENTITY建模 59
5．2．2 設計標識操作 60
5．3 模式：VALUE OBJECT 62
5．3．1 設計VALUE OBJECT 64
5．3．2 設計包含VALUE OBJECT的關聯 67
5．4 模式：SERVICE 67
5．4．1 SERVICE與孤立的領域層 69
5．4．2 粒度 70
5．4．3 對SERVICE的訪問 70
5．5 模式：ＭODULE（也稱為PACKAGE） 71
5．5．1 敏捷的MODULE 72
5．5．2 通過基礎設施打包時存在的隱患 73
5．6 建模范式 75
5．6．1 對象范式流行的原因 76
5．6．2 對象世界中的非對象 77
5．6．3 在混合范式中堅持使用MODEL-DRIVEN DESIGN 78
第6章 領域對象的生命周期 80
6．1 模式：AGGREGATE 81
6．2 模式：FACTORY 89
6．2．1 選擇FACTORY及其應用位置 91
6．2．2 有些情況下只需使用構造函數 93
6．2．3 接口的設計 94
6．2．4 固定規則的相關邏輯應放置在哪里 94
6．2．5 ENTITY FACTORY與VALUE OBJECT FACTORY 95
6．2．6 重建已存儲的對象 95
6．3 模式：REPOSITORY 97
6．3．1 REPOSITORY的查詢 101
6．3．2 客戶代碼可以忽略REPOSITORY的實現，但開發人員不能忽略 102
6．3．3 REPOSITORY的實現 103
6．3．4 在框架內工作 104
6．3．5 REPOSITORY與FACTORY的關系 104
6．4 為關系數據庫設計對象 106
第7章 使用語言：一個擴展的示例 108
7．1 貨物運輸系統簡介 108
7．2 隔離領域：引入應用層 110
7．3 將ENTITY和VALUE OBJECT區別開 110
7．4 設計運輸領域中的關聯 112
7．5 AGGREGATE邊界 113
7．6 選擇REPOSITORY 113
7．7 場景走查 115
7．7．1 應用程序特性舉例：更改Cargo的目的地 115
7．7．2 應用程序特性舉例：重復業務 116
7．8 對象的創建 116
7．8．1 Cargo的FACTORY和構造函數 116
7．8．2 添加Handling Event 117
7．9 停一下，重構：Cargo AGGREGATE 的另一種設計 118
7．10 運輸模型中的ＭODULE 120
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 如何為那些不太明顯的概念建?！?50
9．2．1 顯式的約束 151
9．2．2 將過程建模為領域對象 153
9．2．3 模式：SPECIFICATION 154
9．2．4 SPECIFICATION的應用和實現 156
第 10章 柔 性 設 計 168
10．1 模式：INTENTION-REVEALING
INTERFACES 169
10．2 模式：SIDE-EFFECT-FREE FUNCTION 173
10．3 模式：ASSERTION 177
10．4 模式：CONCEPTUAL CONTOUR 181
10．5 模式：STANDALONE CLASS 184
10．6 模式：CLOSURE OF OPERATION 186
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 模式：COMPOSITE 221
12．3 為什么沒有介紹FLYWEIGHT 226
第 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 CONTEXT 235
14．2 模式：CONTINUOUS INTEGRATION 239
14．3 模式：CONTEXT MAP 241
14．3．1 測試CONTEXT的邊界 247
14．3．2 CONTEXT MAP的組織和文檔化 247
14．4 BOUNDED CONTEXT之間的關系 248
14．5 模式：SHARED KERNEL 248
14．6 模式：CUSTOMER/SUPPLIER DEVELOPMENT TEAM 250
14．7 模式：CONFORMIST 253
14．8 模式：ANTICORRUPTION LAYER 255
14．8．1 設計ANTICORRUPTION LAYER的接口 256
14．8．2 實現ANTICORRUPTION LAYER 256
14．8．3 一個關于防御的故事 259
14．9 模式：SEPARATE WAY 260
14．10 模式：OPEN HOST SERVICE 261
14．11 模式：PUBLISHED LANGUAGE 262
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 KERNEL 273
14．14．2 合并CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION 274
14．14．3 逐步淘汰遺留系統 275
14．14．4 OPEN HOST SERVICE→PUBLISHED LANGUAGE 276
第 15章 精煉 277
15．1 模式：CORE DOMAIN 278
15．1．1 選擇核心 280
15．1．2 工作的分配 280
15．2 精煉的逐步提升 281
15．3 模式：GENERIC SUBDOMAIN 282
15．3．1 通用不等于可重用 286
15．3．2 項目風險管理 287
15．4 模式：DOMAIN VISION STATEMENT 287
15．5 模式：HIGHLIGHTED CORE 289
15．5．1 精煉文檔 289
15．5．2 標明CORE 290
15．5．3 把精煉文檔作為過程工具 291
15．6 模式：COHESIVE MECHANISM 292
15．6．1 GENERIC SUBDOMAIN與COHESIVE MECHANISM的比較 293
15．6．2 MECHANISM是CORE DOMAIN一部分 294
15．7 通過精煉得到聲明式風格 294
15．8 模式：SEGREGATED CORE 295
15．8．1 創建SEGREGATED CORE的代價 296
15．8．2 不斷發展演變的團隊決策 296
15．9 模式：ABSTRACT CORE 301
15．10 深層模型精煉 302
15．11 選擇重構目標 302
第 16章 大型結構 303
16．1 模式：EVOLVING ORDER 306
16．2 模式：SYSTEM METAPHOR 308
16．3 模式：RESPONSIBILITY LAYER 309
16．4 模式：KNOWLEDGE LEVEL 321
16．5 模式：PLUGGABLE COMPONENT FRAMEWORK 328
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
展開全部
領域驅動設計 軟件核心復雜性應對之道 修訂版 作者簡介
Eric Evans “領域驅動設計之父”，世界杰出軟件建模專家。他創建了Domain Language公司，致力于幫助公司機構創建與業務緊密相關的軟件。他在世界各地宣講領域驅動設計（Domain-Driven Design，DDD）的思想，開設課程，參加會議，接受專訪，擁有大批的追隨者。從20世紀80年代開始，他就以設計師和程序員的雙重身份參與過許多大型面向對象系統的設計和開發，涉及各種復雜的業務和技術領域。同時，他還培訓和指導過許多開發團隊開展極限編程實踐。
書友推薦
- >
唐代進士錄
- >
山海經
- >
朝聞道
- >
伊索寓言-世界文學名著典藏-全譯本
- >
有舍有得是人生
- >
小考拉的故事-套裝共3冊
- >
莉莉和章魚
- >
龍榆生：詞曲概論/大家小書
本類暢銷
