2006年，国内的互联网才刚刚萌芽，人们甚至还不习惯网购，大多数在校生都在宿舍里刷魔兽世界副本。但企业软件开发却得到了蓬勃发展，各种公司和事业单位都纷纷进行信息化转型。

然而人们很快发现，企业应用业务逻辑的复杂度要远远高于技术本身，且企业IT人员很难描述清楚他们真正的业务，广大程序员也普遍缺乏挖掘真正需求的能力。整个开发过程更多的是瀑布式的，开发人员一次性收集需求，可能半年后才会和业务人员再次沟通。大多数企业软件就是在这样的环境下，硬着头皮上线的，其质量可想而知。

随着《领域驱动设计》中文版的首次发布，DDD（Domain-Driven Design，领域驱动设计）的概念正式进入中国。当时业界普大喜奔，认为它能指导程序员更精准地收集领域知识，进行更合理的设计，企业应用的银弹出现了。

当时的我正处于多层架构的启蒙阶段，挣扎于企业系统的泥潭，又刚刚被Martin Fowler的《企业应用架构》洗了一遍脑，自然也随波逐流地买了一本，捧在手里翻来翻去。但反反复复就是看不懂。当时以为在贫血模型里面加几个方法就是领域模型了，把DAL或DAO改名成Repository就是资源库了。而且身为程序员，自然愿意去关注那些能指导我们写代码的战术设计方法，那些真正能帮助我们进行合理设计的战略设计方法，则视而不见（可能是因为看也看不懂）。

多年过去，这本书仍然作为我的镇宅之宝戳在书架显眼的位置，希望能有识货的朋友来访时能一眼瞧见，伸出大拇指羡慕嫉妒地说这么老的书你都有。或者偶尔拿出来拍张照片在朋友圈晒晒，以炫耀自己当初的见识。或者随便翻开一页，把鼻子凑上去闻一闻来自12年前的墨香。

7年之后Vaughn Vernon出版了Implement Domain-Driven Design，简称IDDD。一年之后由同事翻译的中文版《实现领域驱动设计》也相应出版，当时被看做是能让DDD落地的书（毕竟书名里有个“实现”嘛）。然而我在项目技术负责人的带领下，在众多有经验的架构师的指导下，仍然没有弄明白。之前看过的相关知识均已遗忘殆尽。限界上下文、上下文映射这些名词只是似曾相识。

两年之后《领域驱动设计模式、原理与实践》问世，简称PPPDDD。社区对这本书的评价非常之高，甚至认为在IDDD之上。只可惜翻译这本书的蒲成先生是莆田系翻译，他不但根本不懂DDD，甚至可能不懂软件开发。这就很尴尬。我翻了几页之后又束之高阁了。

今年年初，项目上的架构小组又开始组织学习DDD。所使用的“教材”是英文版的PPPDDD。在同事的激励下，我开始重整旗鼓，啃这本英文版大部头。开始精读之后，才发现这是一本很水的好书。说它水是因为它的编排并不足够细心，甚至有不同章节的两段文字完全相同的现象，还会花30页的篇幅去介绍一个基于NHibernate的资源库实现。说它好是因为面面俱到，把所有战略模式和战术模式都介绍了个遍，还有大量代码去帮你实现各种战术模式，可以说相当落地。

在学习的过程中，我常常翻阅IDDD中的相关章节进行补充阅读，发现当初晦涩难懂的概念慢慢变得容易起来。应用服务和领域服务不再傻傻分不清楚，不同的上下文映射方式也能在工作中找到对应的例子。对于DDD，感觉快要开始入门了。

与此同时，IDDD的精华版DDDD（Domain-Driven Design Distilled）也出版了。作者总结了过去几年在DDD方面的实战经验，将IDDD中的诸多内容精简升华。在很多概念处都标注了IDDD中的相关章节，可以算是IDDD的一个索引。

其中文版《领域驱动设计精粹》由我的同事覃宇和笪磊合作翻译。这是我读过的最良心的一本书籍。因为它包含了大量译者注解，解释了很多书中没有解释清楚的概念（毕竟是精粹本）。还有些有争议的观点，译者也毫不客气地给出自己的看法。

像这样注解超过原文的情况在其他书中是很少见的。每一处注解都倾注了译者的心血和精力，这背后势必包括大量资料的查阅和研究，而且很多解释都夹带了浓浓的ThoughtWorks特色。这使得这样一本薄薄的书变得丰满充实起来。

如果你读书快的话，可能两个小时就读完这样一本书。但如果把原书和注解中的推荐文章和书籍读完，恐怕要一个月。我顺着书中的指引，找到了ThoughtWorks洞见上的所有DDD文章，读完之后，世界观崩塌了，感觉自己刚要入门就要放弃了。具体原因请参考链接中的文章。

其实，不管是DDD、IDDD、PPPDDD还是DDDD，讲的都是理论，充其量会附加一些作者杜撰的示例。相信我，光学习理论是没有用的，你必须将其应用于实践，在自己的真实项目里演练DDD。这时你才会发现，那些白纸黑字的概念，在读书时似乎搞清楚了，但一使用起来，反而更迷惑了。就像最基本的子域和限界上下文的关系问题，ThoughtWorks的首席咨询师肖然就和Vaughn Vernon的理解就相去甚远。到底该“信谁”？那就似乎更要通过实践来出真知了。