.1.4.3　更多信息 28
1.5　不要忘记运行机制 28
1.5.1　有关何时需要运行机制的一个例子 29
1.5.2　运行机制的一些例子 29
1.5.3　它不仅仅是我们的过错 30
1.6　小结 30
第2章　模式起步 32
2.1　模式概述 32
2.1.1　为什么要学习模式 33
2.1.2　在模式方面要注意哪些事情 34
2.2　设计模式 35
2.3　架构模式 42
2.3.1　示例：层 42
2.3.2　另一个示例：领域模型模式 43
2.4　针对具体应用程序类型的设计模式 43
2.5　领域模式 48
2.6　小结 52
第3章　TDD与重构 53
3.1　TDD 53
3.1.1　TDD流程 53
3.1.2　演示 54
3.1.3　设计效果 59
3.1.4　问题 61
3.1.5　下一个阶段 62
3.2　模拟和桩 62
3.2.1　典型单元测试 62
3.2.2　声明独立性 63
3.2.3　处理困难因素 64
3.2.4　用测试桩替换协作对象 64
3.2.5　用模拟对象替换协作对象 66
3.2.6　设计含义 68
3.2.7　结论 68
3.2.8　更多信息 68
3.3　重构 68
3.4　小结 78
第二部分　应用DDD
第4章　新的默认架构 80
4.1　新的默认架构的基础知识 80
4.1.1　从以数据库为中心过渡到以领域模型为中心 81
4.1.2　进一步关注DDD 81
4.1.3　根据DDD进行分层 82
4.2　轮廓 83
4.2.1　领域模型示例的问题/特性 83
4.2.2　逐个处理特性 84
4.2.3　到目前为止的领域模型 94
4.3　初次尝试将UI与领域模型挂接 95
4.3.1　基本目标 95
4.3.2　简单UI的当前焦点 95
4.3.3　为客户列出订单 95
4.3.4　添加订单 97
4.3.5　刚才我们看到了什么 98
4.4　另一个维度 98
4.4.1　领域模型的位置 99
4.4.2　孤立或共享的实例 99
4.4.3　有状态或无状态领域模型实例化 100
4.4.4　领域模型的完整实例化或子集实例化 100
4.5　小结 101
第5章　领域驱动设计进阶 102
5.1　通过简单的TDD实验来精化领域模型 102
5.1.1　从Order和OrderFactory的创建开始 103
5.1.2　一些领域逻辑 106
5.1.3　第二个任务：OrderRepository + OrderNumber 107
5.1.4　重建持久化的实体：如何从外部设置值 111
5.1.5　获取订单列表 114
5.1.6　该到讨论实体的时候了 115
5.1.7　再次回到流程上来 116
5.1.8　总览图 117
5.1.9　建立OrderRepository的伪实现 118
5.1.10　简单讨论一下保存 120
5.1.11　每个订单的总量 120
5.1.12　历史客户信息 124
5.1.13　实例的生命周期 126
5.1.14　订单类型 128
5.1.15　订单的介绍人 128
5.2　连贯接口 130
5.3　小结 131
第6章　准备基础架构 132
6.1　将POCO作为工作方式 133
6.1.1　实体和值对象的PI 133
6.1.2　是否使用PI 137
6.1.3　运行时与编译时PI 137
6.1.4　PI实体/值对象的代价 137
6.1.5　将PI用于存储库.. 139
6.1.6　单组存储库的代价 143
6.2　对保存场景的处理 143
6.3　建立伪版本机制 147
6.3.1　伪版本机制的更多特性 148
6.3.2　伪版本的实现 149
6.3.3　影响单元测试 150
6.4　 数据库测试 153
6.4.1　在每次测试之前重置数据库 154
6.4.2　在测试运行期间保持数据库的状态 155
6.4.3　测试之前重置测试所使用的数据 156
6.4.4　不要忘记不断演变的模式 156
6.4.5　分离单元测试和数据库调用测试 156
6.5　查询 159
6.5.1　单组查询对象 160
6.5.2　单组查询对象的代价 161
6.5.3　将查询定位到哪里 162
6.5.4　再次将聚合作为工具 163
6.5.5　将规格用于查询 164
6.5.6　其他查询选择 165
6.6　小结 165
第7章　应用规则 166
7.1　规则的分类 166
7.2　规则的原则及用法 167
7.2.1　双向规则检查：可选的（可能的）主动检查，必需的（和自动的）被动检查 167
7.2.2　所有状态（即使是错误状态）都应该是可保存的 167
7.2.3　规则应该高效使用 167
7.2.4　规则应该是可配置的，以便添加自定义规则 167
7.2.5　规则应与状态放在一起 167
7.2.6　规则应该具有很高的可测试性 168
7.2.7　系统应阻止我们进入错的状态 168
7.3　开始创建API 168
7.3.1　上下文，上下文，还是上下文 169
7.3.2　数据库约束 169
7.3.3　将规则绑定到与领域有关的转换，还是绑定到与基础架构有关的转换 170
7.3.4　精化原则：所有状态，即使是错误状态，都应该是可保存的 171
7.4　与持久化有关的基本的规则API的需求 172
7.4.1　回到已发现的API问题上 173
7.4.2　问题是什么 173
7.4.3　我们允许了不正确的转换 174
7.4.4　如果忘记检查怎么办 174
7.5　关注与领域有关的规则 174
7.5.1　需要合作的规则 176
7.5.2　使用基于集合的处理方法 177
7.5.3　基于服务的验证 178
7.5.4　在不应该转换时尝试转换 179
7.5.5　业务ID 180
7.5.6　避免问题 182
7.5.7　再次将聚合作为工具 183
7.6　扩展API 183
7.6.1　查询用于设置UI的规则 184
7.6.2　使注入规则成为可能 184
7.7　对实现进行精化 184
7.7.1　一个初步实现 184
7.7.2　创建规则类，离开最不成熟的阶段 189
7.7.3　设置规则列表 191
7.7.4　使用规则列表 192
7.7.5　处理子列表 192
7.7.6　一个API改进 193
7.7.7　自定义 194
7.7.8　为使用者提供元数据 195
7.7.9　是否适合用模式来解决此问题 195
7.7.10　复杂规则又是什么情况 195
7.8　绑定到持久化抽象 196
7.8.1　使验证接口成为可插入的 196
7.8.2　在保存方面实现被动验证的替代解决方案 197
7.8.3　重用映射元数据 198
7.9　使用泛型和匿名方法 198
7.10　其他人都做了什么 199
7.11　小结 200
第三部分　应用PoEAA
第8章　用于持久化的基础架构 202
8.1　持久化基础架构的需求 203
8.2　将数据存储到哪里 204
8.2.1　RAM 204
8.2.2　文件系统 205
8.2.3　对象数据库 206
8.2.4　关系数据库 207
8.2.5　使用一个还是多个资源管理器 207
8.2.6　其他因素 207
8.2.7　选择和前进 207
8.3　方法 208
8.3.1　自定义手工编码 208
8.3.2　自定义代码的代码生成 209
8.3.3　元数据映射（对象关系（O/R）映射工具） 210
8.3.4　再次选择 211
8.4　分类 211
8.4.1　领域模型风格 211
8.4.2　映射工具风格 212
8.4.3　起点 212
8.4.4　API焦点 213
8.4.5　查询风格 213
8.4.6　高级数据库支持 214
8.4.7　其他功能 215
8.5　另一个分类：基础架构模式 216
8.5.1　元数据映射：元数据的类型 216
8.5.2　标识字段 217
8.5.3　外键映射 219
8.5.4　嵌入值 219
8.5.5　继承解决方案 219
8.5.6　标识映射 220
8.5.7　操作单元 220
8.5.8　延迟加载/立即加载 220
8.5.9　并发控制 221
8.6　小结 222
第9章　应用NHibernate 223
9.1　为什么使用NHibernate 223
9.2　NHibernate简介 224
9.2.1　准备 224
9.2.2　一些映射元数据 225
9.2.3　一个小的API示例 229
9.2.4　事务 231
9.3　持久化基础架构的需求 232
9.3.1　高级持久化透明 232
9.3.2　持久化实体的生命周期所需的特定特性 233
9.3.3　谨慎处理关系数据库 234
9.4　分类 235
9.4.1　领域模型风格 235
9.4.2　映射工具风格 235
9.4.3　起点 236
9.4.4　API焦点 236
9.4.5　查询语言风格 236
9.4.6　高级数据库支持 237
9.4.7　其他功能 239
9.5　另一种分类：基础架构模式 240
9.5.1　元数据映射：元数据类型 240
9.5.2　标识字段 240
9.5.3　外键映射 241
9.5.4　嵌入值 241
9.5.5　继承解决方案 242
9.5.6　标识映射 243
9.5.7　操作单元 244
9.5.8　延迟加载/立即加载 244
9.5.9　并发性控制 244
9.5.10　额外功能：验证挂钩 245
9.6　NHibernate和DDD 245
9.6.1　程序集概览 245
9.6.2　ISession和存储库 246
9.6.3　ISession、存储库和事务 246
9.6.4　得到了什么结果 247
9.7　小结 247
第四部分　下一步骤
第10章　博采其他设计技术 250
10.1　上下文为王 250
10.1.1　层和分区 250
10.1.2　分区的原因 251
10.1.3　限界上下文 252
10.1.4　限界上下文与分区有何关联 252
10.1.5　向上扩展DDD项目 252
10.1.6　为什么对领域模型——SO分区 253
10.2　SOA简介 253
10.2.1　什么是SOA 253
10.2.2　为什么需要SOA 253
10.2.3　SOA有什么不同 254
10.2.4　什么是服务 254
10.2.5　服务中包括什么 254
10.2.6　深入分析4条原则 255
10.2.7　再来看一下什么是服务 256
10.2.8　OO在SOA中的定位 256
10.2.9　客户—服务器和SOA 257
10.2.10　单向异步消息传递 257
10.2.11　SOA如何提高可伸缩性 258
10.2.12　SOA服务的设计 258
10.2.13　服务之间如何交互 259
10.2.14　SOA和不可用的服务 261
10.2.15　复杂的消息传递处理 262
10.2.16　服务的可伸缩性 262
10.2.17　小结 263
10.3　控制反转和依赖注入 263
10.3.1　任何对象都不是孤岛 263
10.3.2　工厂、注册类和服务定位器 265
10.3.3　构造方法依赖注入 267
10.3.4　setter依赖注入 269
10.3.5　控制反转 270
10.3.6　使用了Spring.NET框架的依赖注入 271
10.3.7　利用PicoContainer.NET进行自动装配 272
10.3.8　嵌套容器 273
10.3.9　服务定位器与依赖注入的比较 275
10.3.10　小结 275
10.4　面向方面编程 276
10.4.1　热门话题有哪些 277
10.4.2　AOP术语定义 279
10.4.3　.NET中的AOP 280
10.4.4　小结 291
10.5　小结 291
第11章　关注UI 292
11.1　提前结语 292
11.2　模型—视图—控制器模式 293
11.2.1　示例：Joe的Shoe Shop程序 294
11.2.2　通过适配器简化视图界面 299
11.2.3　将控制器从视图解耦 299
11.2.4　将视图和控制器结合起来 300
11.2.5　是否值得使用MVC 300
11.3　测试驱动的Web窗体 300
11.3.1　背景 301
11.3.2　一个示例 301
11.3.3　领域模型 302
11.3.4　GUI的TDD 302
11.3.5　Web窗体实现 307
11.3.6　小结 309
11.3.7　用NMock创建模拟 309
11.4　映射和包装 311
11.4.1　映射和包装 311
11.4.2　用表示模型来包装领域模型 312
11.4.3　将表示模型映射到领域模型 313
11.4.4　管理关系 316
11.4.5　状态问题 318
11.4.6　最后的想法 319
11.5　小结 320
11.6　结束语 320
第五部分　附　　录
附录A　其他领域模型风格 324
附录B　已讨论的模式的目录... 349

.本书面向广泛的读者。具备以下知识有助于阅读本书。
·面向对象
·.NET或类似平台
·C#或类似语言
·关系数据库，例如SQL Server
但是，兴趣和热情可以弥补任何经验的不足。
这里再详细解释一下为什么目标读者是广泛的。首先，我们从平台框架来考虑一下适用的人员。本书面向那些需要一种更关注核心的方法而不是简单的拖放操作（可能这个概括并不是很恰当）的.NET开发人员。Java开发人员可以从如何结合DDD和O/R映射的讨论及示例中获益。
我认为选定的语言和平台越来越不重要了，因此谈论.NET开发人员和Java开发人员看起来有些不合时宜。那么就让我们试着用另一种角度来描述目标读者，即，本书是面向开发人员、团队领导者和架构师的。
选择这种角度后，我认为本书中有些内容既适合中级读者，也适合高级读者。可能也会有些内容适合初级读者。
本书的组织
本书共分四部分：背景知识、应用DDD、应用PoEAA和下一步骤。
第一部分：背景知识
背景知识这一部分概括地讨论架构和过程，重点讲解领域模型和DDD（领域驱动设计）[Evans DDD]，还将介绍模式和TDD（测试驱动开发）。第一部分包括以下几章。
·第1章，应重视的价值
该章讨论要想得到高质量的系统开发结果，应重视的架构属性和过程。这一章的讨论受到极限编程（XP）的影响。
·第2章，模式起步
该章主要提供示例，并讨论不同类型的模式，例如设计模式、架构模式和领域模式。
·第3章，TDD与重构
第1章讨论了很多TDD和重构内容，而这一章则通过较长的示例并着眼于不同的TDD风格来深入阐述这些内容。
第二部分：应用DDD
这一部分介绍DDD的应用。此外还会为基础架构准备领域模型，重点关注规则方面。
·第4章，新的默认架构
该章列出了示例应用程序的各方面需求，并初步创建了一个模型作为后续章节的起点。这里使用了基于领域模型的架构。
·第5章，领域驱动设计进阶
这一章使用第4章中提出的需求作为开始构建DDD风格的领域模型的基础。在这一章中，由于是刚开始使用TDD方法，因此我们放慢构建速度。
·第6章，准备基础架构
尽管我们尽量推迟基础架构方面，但还是有必要稍微提前思考一下，并针对基础架构需求为领域模型做一些准备。这一章讨论持久化透明（PI）领域模型的利弊。
·第7章，遵守规则
这一章讨论验证形式的业务规则，以及基于领域模型的解决方案如何处理这样的规则需求，从而与第4章中的需求联系起来。
第三部分：应用PoEAA
在这一部分中，我们将Fowler的《企业应用架构模式》[Fowler PoEAA]中的几种模式作为上下文，以此来讨论基础架构需要为领域模型提供哪些持久化支持。我们将看一下如何通过示例工具来满足这些需求。
·第8章，用于持久化的基础架构
当我们拥有了很好的领域模型时，就该好好考虑基础架构了，本书中的主要基础架构类型是用于持久化的基础架构。第8章讨论持久化解决方案的不同属性，以及如何对特定解决方案进行分类。
·第9章，NHibernate实战
这一章通过一个持久化解决方案的示例来使用前一章中的分类，这个示例就是NHibernate[NHibernate]。
第四部分：下一步骤
这一部分主要关注并开始使用其他一些设计技术。另外一个重点是如何在领域模型中处理表示层，以跨越领域模型与表示层之间的鸿沟，此外还将介绍开发人员如何测试UI。这一部分几乎都是邀请其他作者编写的。
·第10章，博采其他设计技术
这一章首先简单讨论限界上下文（bounded context），然后讨论现在和将来都应关注的一些设计技术，例如面向服务、依赖注入/控制反转，以及面向方面。
·第11章，关注UI
这一章主要讨论如何将UI连接到领域模型，以及在使用领域模型时如何提高富客户端应用程序和Web应用程序用户界面的可测试性。
附录
本书有两个附录，附录A包含更多领域模型风格的示例，附录B提供了简明的模式目录。
关于C#示例
本书绝不是一本讲述C#的书。但我仍需要一种用于编写示例的语言（语言有多种，但我必须从中选择一种），这样就选择了C#。
选择C#的主要原因是我当前经常使用它，而且大多数VB.NET和Java开发人员都很容易看懂C#代码。
至于版本方面，本书大部分示例代码可以同时在C# 1.1和2.0中运行，个别章节的代码只能在C# 2.0中运行。
未涵盖的主题
本书中未涵盖的主题有很多，最主要的是分布式和高级建模。
分布式
本书最早的写作计划中是包含分布式方面的完整讨论的，但后来我发现这样本书的重点就过于分散了。但一些章节中仍然穿插了一些这方面的内容。
高级建模
本书的书名可能暗示书中会包含特定问题领域的一些高级和有趣的建模示例，但事实并不是这样。我们示例的重点更多地放在了应用TDD以及为DDD添加基础架构上。
最后的感言
相信读者能够理解，像本书这样的项目几乎从来不是一个人就能完成的。它是很多人共同努力的结果。请参见致谢部分的人员名单，但还有更多参与人员未在这个名单中列出，特别是那些负责本书印制的人。虽然如此，但任何在印刷之前未发现的错误都应归咎于我一个人。
我将把读者感兴趣的一些信息发布到网上：www.jnsk.se/adddp。
再回头说说跨越鸿沟，厄勒海峡大桥的照片是我的朋友Magnus von Schenck在他的一次海上旅行中拍摄的。
尽管本书的创作不像第一本书那样艰辛，但其中也凝聚了无数的心血、汗水和泪水。我希望通过我的这些付出，能够减少读者的付出。最后愿读者从阅读本书中获得乐趣，祝你们好运！...
Jimmy Nilsson
www.jnsk.se/weblog/
2005年9月于瑞典Listerby

.对很多人来说，本书将填补一个空白，教会大家怎样在实践中实现富有表现力的对象模型。我从本书学到不少思考技术框架应用的有用方法，尤其是加强了我对在.NET平台上使用DDD方法的一些理解。
除了技术架构以外，Jimmy还在如何编写测试上花费了大量时间。TDD以一种不同方式补充了DDD。当对于精化更有用模型的重视程度不够时，TDD容易导致零散的应用，这时对某一特性的一味追求会使系统最终无法扩展。综合的测试套件实际上使开发团队能够继续取得进展（与没有TDD时相比），但这只是TDD的最基本价值。
当测试套件充分发挥作用时，它是域模型的实验室，也是通用语言的技术表示。特殊风格的测试推动建模过程向前发展，并保持整个建模过程始终围绕重点展开。开发这些测试的示例贯穿了本书。
Jimmy Nilsson集自信和谦逊于一身，我注意到这是最优秀设计人员的特征。当他说到以前习惯于相信什么，后来为什么观点又改变的时候，我们可以管窥到他是如何获得当前理解的，这帮助读者穿越技术细节，从而理解基本原则。这种谦虚的品质帮助他集思广益，并因此为我们奉上了这本融合各种不同思想的书。他做了各种各样的尝试，并用结果和经验作为自己的指导。他的结论不是以被揭示的真理的面目出现，而是作为他到目前为止的最佳理解，其中的奥妙令我们回味无穷。所有这些都使得他的建议对读者更有用。而且这种态度本身也是领导成功软件开发所需的一个重要元素。...
Eric Evans

.最后，我希望我们的行业能够更好地用代码表达丰富的概念，能够在表达和演进共享知识的社会化过程中做得更好。TDD和DDD都是实现这些目标的核心技术。”
Edward Jezierski，微软模式和实践架构师
“Jimmy将领域驱动设计、测试驱动开发、重构和设计模式的技术精华整合为一体，可以令人信服地取代已成为Microsoft应用程序的中流砥柱的数据驱动开发风格。本书的核心为领域驱动设计中倡导的技术赋予了生命。它具有非常强的实用性，帮助读者深入地理解思考过程，从而为运用成熟技巧和技术打下坚实基础。而且，像Jimmy的所有作品一样，本书非常简单易读，好样的，Jimmy！”
Christian Crowhurst，分析师，开发者
“到目前为止，我已经在一个合作项目上与Jimmy共事18个月了。Jimmy真正按他所说的那样去做了。在本书中，他告诉读者他在实践中是如何工作的。他每天都使用O/R映射和NHibernate，也真正使用TDD来帮助理解和提炼客户的业务逻辑，并确保只交付经过测试的高质量代码，如同他写的这本高质量的书一样，包含的概念都经过了测试。好好享受本书吧。”
Dan Bystr?m，软件开发人员，www.visual-design.se/blog
“通过展示如何应用领域驱动设计和企业应用模式，Jimmy让更广泛的读者能够理解这个困难的主题。本书有些内容适合经验丰富的架构师和积极的模式实现人员。事实上，任何想要改进软件解决方案设计和实现方法的开发人员或架构师都应该阅读本书。”
Per-Ola Nilsson，Luvit的开发主管和软件架构师
“Jimmy总是站在软件开发最新趋势的前沿，但却从不会迷失方向，他最擅长的就是去粗取精。他兼备谦逊的品质和集思广益的精神，因此非常适合指导和启发读者，他将实际可用性作为标准，而避开象牙塔。Jimmy并不是居高临下地提供帮助，而是设法让读者感觉到正在向一位同事学习最前沿的技术。”
Mats Helander，软件开发人员，www.matshelander.com
“就像Jimmy的前一本书一样，本书是一部真正的杰作：它在实际软件工程与深层次理论之间做出了良好的平衡。”
Frans Bouma，LLBLGen Pro的创建者，weblogs.asp.net/fbouma
“本书拥有坚实的基础，Jimmy在运用领域驱动设计的实践中解决实际问题。最后，我们拥有了一本手册，使我们在处理未来基于领域模型的企业应用时，不会由于不断增加的复杂性而碰壁。”
Paul Gielens，Capgemini的高级顾问，weblogs.asp.net/pgielens
“从经验谈起，结合.NET中DDD、DP和TDD的实质，就可以得到非常有效且具有自适应能力的企业软件架构。本书解释了如何以及为什么这些概念共同构成一个强大的整体。因此，本书为读者提供了一个构建成功企业软件架构的宝贵捷径，对于任何相关的开发人员来说，这都是一本必读的书。”
Martin Rosén-Lidholm，Exense Healthcare的软件架构师
“你是否希望用面向对象技术和关系数据库来构建一个高质量企业系统？那么请不要错过本书。Jimmy将为你展示测试驱动开发如何成为整个项目中的驱动力量。他展示了如何将OO设计映射到数据库，通常在其他文献中对这一步的讨论过于简略，单就这一点本书就物有所值。本书还包含大量的设计提示和讨论，让读者可以紧跟作者的推理过程。”
Ingemar Lundberg，一位热情的软件开发人员，www.ingolundberg.com
“这是一本重要且及时的书，对于任何希望进入C#领域驱动设计领域的人来说，它都是一本必读的书。”
Gregory Young，微软C# MVP，独立顾问
“本书讨论了现代软件开发中所使用的一些重要概念，例如测试驱动开发、重构、模式，当然还包括领域驱动设计。Jimmy Nilsson以非常通俗的语言介绍了这些概念，阅读本书时，感觉似乎他正坐在你身边，为你展示他的示例，并亲自与你讨论不同解决方案的利弊。”
Niclas Nilsson，Activa软件开发人员和教育者
“本书出色地将领域驱动设计（DDD）引入实际语境，它在各个不同抽象层之间架起桥梁，从业务角度层向下一直到系统层。本书最适合软件架构师和开发人员，因为其编排方式使得它既可以被用作入门书也可作参考书。作者全面介绍了DDD的所有方面，本书不仅具有教育意义，而且也充满了阅读乐趣。”
Gunther Lenz，项目经理和技术作家
“就在不久前，我在博客上记录了我的总体感受：作为架构师，我们可能无法提供足够的指导，以便让开发人员能够在数百种软件构建方式中做出正确选择。很多开发思想本身都非常优秀，并且有着相当充分的理由和成功示例，还拥有热情的信仰者社区。在这些构建方式当中，只有很少的一些可用来独立构建应用程序，能用来构建应用系统和服务系统的就更少了。这就需要开发人员决定用什么方式将独立的思想整合到应用程序当中。不难想象，在现实中，这比任何特殊方法的提议都要困难得多。另一方面，开发人员需要完成工作，通常不愿意每次开始构建新应用程序时都去全面考虑这一切。甚至在他们真正有兴趣利用新方法或新思想的潜力时，亦是如此。Jimmy的书直接针对这个问题。如何将过去几年中的一些伟大思想应用于实际的、实时的开发？我认为本书做了卓越的工作，它不仅足够详细地解释了基本思想，以便让它们具有实际意义，而且将一系列思想综合到一起，以便帮助开发人员从头至尾地了解整个路线。本书全面涵盖领域驱动设计、测试驱动开发、依赖注入、持久化等很多实际问题。在阅读本书后，我认为读者将真正掌握这些重要思想，并有效地将它们结合起来使用。由于每一种思想都具有极大的价值，但人们真正使用它们的范例却很有限，因此本书对于我们所有人来说是一场共赢。我强烈推荐它。”
Philip Nelson，PAi首席科学家，xcskiwinn.org/community/blogs/panmanphil/default.aspx
“领域驱动设计、测试驱动开发、对象/关系持久化等敏捷方法和模式都涉及较深层的OOP技术。对于刚刚起步的人来说，想要从以数据为中心的思想跨越到较深层次的OOP实现是一件费力且易令人迷惑的任务。
凭借耐心、注重实效和循循善诱的风格，Jimmy带领读者完成了这个跨越过程，研究了问题及各种情形，并在整个过程中提供了合理的建议。本书展示了如何将各种方法和模式整合为一个紧密耦合的方法，从而设计和创建具有高度可维护性的.NET软件。”
George Hicks，Property Works公司高级开发人员
“如果你曾经读过Jimmy Nilsson的博客，那么你会知道他喜欢挑战.NET社区中的现有‘真理’，并寻找更好的软件设计方式。他承认软件设计是困难的，而且并没有通用解决方案；必须对目前问题语境下的利弊进行权衡，才能最终选出一个解决方案。对于构建具有复杂业务需求的、可测试且可维护的软件，Jimmy选择使用领域驱动设计，而且他引入了一个工具箱，其中包含经过检验且公认的原则、模式和实践，用于实施领域驱动设计。Jimmy通俗易懂的写作风格以及对示例和测试驱动开发的运用使得本书非常易于阅读，特别是本书涵盖了所有基础知识。凭借Jimmy对DDD内容的精通，他和他的朋友为读者带来了当今软件开发领域中许多最有价值的技术和资源的精华。我相信本书是应用DDD的宝贵指南，而且适用于所有想要提高总体设计技巧的开发人员。”
Andreas Brink，软件开发人员
“本书加强了Jimmy Nilsson在应用软件架构领域中的权威地位。本书完美地融合了他在各个主题上的个人思想，带领读者了解所有必须掌握的现代设计技术，未留下任何知识上的遗漏。Jimmy通过一种引人入胜且易于理解的结构，展示了如何实现其他思想领袖更理论性的思想。我敢肯定本书将成为企业书架上一本必备的图书。”
Mikael Freidlitz，IASA公司副总裁
“领域驱动设计是一项重要技术，它能够帮助创建随业务需求演进的高质量业务应用程序。在理想世界中，DDD实践就是关于OO设计的，但在现实世界中，我们所使用的技术强加了大量约束。
本书直面这个挑战，它在DDD概念与将这些概念转化为.NET平台实践之间架起一座桥梁。Jimmy不仅对DDD和企业技术有着深刻理解，而且从丰富的行业经验中汲取了很多经验教训，并采用了一种全新的实用方法。这是一本极有价值的书。”
Rod Johnson，Spring Framework的创立者，Interface21的CEO
“这是一本优秀的书。它将读者带入领域驱动设计世界的实用、博学之旅。本书在相关语境中讨论、解释和展示了大量重要问题。这些知识将为读者使用自己的基于域模型的系统打下坚实基础。本书既讨论了实际开发技术，也讨论了实用的工作方法（与测试驱动开发结合起来）。”
Trond-Eirik Kolloen，软件架构师和开发人员
“现在我们能集中精力修修房子了吗？”
我的妻子，Lotta
“Aaa, dee, dee, dee, pee...”（用瑞典语发音读本书书名首字母）
我的儿子Leo，4岁
“爸爸，你真认为有人会看这本书吗？”...
我的儿子Tim，8岁