第一部分 让领域模型发挥作用 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