领域驱动设计 软件核心复杂性应对之道PDF电子书下载

第一部分 让领域模型发挥作用 5

第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“大声地”建模 21

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

第二部分 模型驱动设计的构造块 43

第4章 分离领域 43

4.1模式：LAYERED ARCHITECTURE 43

4.1.1将各层关联起来 46

4.1.2架构框架 47

4.2模型属于领域层 48

4.3模式：THE SMART UI“ANTI-PATTERN” 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 OBJECT 62

5.3.1设计VALUE OBJECT 64

5.3.2设计包含VALUE OBJECT的关联 67

5.4模式：SERVICE 67

5.4.1SERVICE与孤立的领域层 69

5.4.2粒度 70

5.4.3对SERVICE的访问 70

5.5模式：MODULE（也称为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.5ENTITY FACTORY与VALUE OBJECT FACTORY 95

6.2.6重建已存储的对象 95

6.3 模式：RFPOSITORY 97

6.3.1RFPOSITORY的查询 101

6.3.2客户代码可以忽略RFPOSITORY的实现，但开发人员不能忽略 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设计运输系统中的关联 111

7.5AGGREGAIE边界 113

7.6选择REPOSITORY 113

7.7场景走查 115

7.7.1应用程序特性举例：更改Cargo的目的地 115

7.7.2应用程序特性举例：重复业务 116

7.8对象的创建 116

7.8.1Cargo的FACTORY和构造函数 116

7.8.2添加一个Handling Event 117

7.9停下来重构：Cargo AGGREGATE的另一种设计 118

7.10运输模型中的MODULE 120

7.11引入新特性：配额检查 122

7.11.1连接两个系统 123

7.11.2进一步完善模型：划分业务 124

7.11.3性能优化 125

7.12小结 126

第三部分 通过重构来加深理解 131

第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模式：SPE CIFICATION 154

9.2.4SPECIFICATION的应用和实现 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模式：STANDAL ONE 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模式：STR ATEGY（也称为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

第四部分 战略设计 233

第14章 保持模型的完整性 233

14.1模式：BOUNDED CONTEXT 235

14.2模式：CONTINUOU S INTEGRATION 239

14.3模式：CONTEXT MAP 241

14.3.1测试CONTEXT的边界 247

14.3.2CONTEXT MAP的组织和文档化 247

14.4BOUNDED 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实现ANTICORRUPTICN 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合并C0NTEXT:SEPARATE WAY→SHAREDKERNEL 273

14.14.2合并CONTEXT:SHARED KERNEL→CONTINUOUS IN TE GRATION 274

14.14.3逐步淘汰遗留系统 275

14.14.4OPEN 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通过精炼得到声明式风格 295

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

结束语 350

附录 350

术语表 353

参考文献 356

图片说明 358

索引 359