領域驅動設計 : 軟件核心複雜性應對之道 领域驱动设计:软件核心复杂性应对之道
埃里克·埃文斯 (Eric Evans)
- 出版商: 人民郵電
- 出版日期: 2016-06-01
- 定價: $599
- 售價: 8.5 折 $509
- 語言: 簡體中文
- 頁數: 370
- 裝訂: 平裝
- ISBN: 7549956634
- ISBN-13: 9787115376756
-
相關分類:
Domain-Driven Design
- 此書翻譯自: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)
-
相關翻譯:
領域驅動設計:軟體核心複雜度的解決方法 (Domain-Driven Design: Tackling Complexity in the Heart of Software) (繁中版)
立即出貨 (庫存 < 4)
買這商品的人也買了...
-
$880$695 -
$800$632 -
$653實現領域驅動設計 (Implementing Domain-Driven Design)
-
$780$616 -
$281程序員修煉之道 :從小工到專家 (The Pragmatic Programmer: From Journeyman to Master)
-
$301軟件架構師的 12項修煉 (技術技能篇)
-
$390$332 -
$780$616 -
$509領域驅動設計模式、原理與實踐
-
$599$569 -
$580$458 -
$420$332 -
$580$458 -
$266軟技能代碼之外的生存指南 (Soft Skills : The software developer's life manual)
-
$403Laravel 框架關鍵技術解析
-
$301軟件設計重構
-
$352代碼不朽:編寫可維護軟件的10大要則(C#版)
-
$327大數據架構詳解:從數據獲取到深度學習
-
$450$356 -
$580$493 -
$500$395 -
$234$222 -
$390$332 -
$580$452 -
$390$371
相關主題
商品描述
<內容介紹>
本書是領域驅動設計方面的經典之作,修訂版更是對之前出版的中文版進行了全面的修訂和完善。
全書圍繞著設計和開發實踐,結合若乾真實的項目案例,向讀者闡述如何在真實的軟件開發中應用領域驅動設計。書中給出了領域驅動設計的系統化方法,並將人們普遍接受的一些實踐綜合到一起,融入了作者的見解和經驗,展現了一些可擴展的設計新實踐、已驗證過的技術以及便於應對複雜領域的軟件項目開發的基本原則。
<章節目錄>
第一部分運用領域模型
第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