本书是 Eric Evans 的《领域驱动模型》一书的精简版，让你在短时间内理解领域驱动设计的内容。这本书没有介绍任何新的概念，它只是概要总结了领域驱动设计的本质，抽取了Eric Evans 原书中关于这一主题的大部分内容，以及其他相关资料，包括已经出版的书籍和各种领域驱动设计讨论群组等。这本书可以让你快速了解领域驱动设计的基础知识，但不能替代Eric 书中提供的大量事例和案例研究或者 Jimmy 书中提供的动手事例等。
目录
- 何为“领域驱动设计”
- 通用语言
- 模型驱动设计
- 面向深层理解的重构
- 保持模型一致性
- 领域驱动设计新进展：专访 Eric Evans
关于本书
Domain-Driven Design Quickly 由 InfoQ.com 网站制作，Abel Avram 和 Floyd Marinescu 总结整理，Floyd Marinescu 为责任编辑。特别感谢 Eric Evans 的支持，和 Vladimir Gitlevich、Dan Bergh Johnsson 的细心审校。《领域驱动设计精简版》由 InfoQ 中文站制作，孙向晖和霍太稳翻译并审校，霍太稳为责任编辑。发行本书的目的在于尽可能地介绍领域驱动设计，促使这一概念成为主流。
修订版序：笨蛋，问题是领域
“笨蛋，问题是经济！”（It's the economy, stupid!） 上面这句带有冒犯性的话，是比尔·克林顿在与老布什竞选美国总统时提出的竞选标语。事实证明，克林顿是美国近 30 年来最懂经济的总统，在他的任内，启动了著名的“信息高速公路”计划，美国的经济蒸蒸日上。所以即使他是一位花花太岁，一度声名狼藉，美国人民至今仍然很怀念他。
对于我们所从事的软件开发行业来说，如果有什么东西像是经济一样永恒，那么无疑就是领域（domain）了。在计算机发展的最初岁月，它主要是用来完成一些计算密集型的工作，例如核试验、天气预报中的庞大的计算工作。后来人们发现计算机很适合用来模拟人类世界很多领域中所存在的业务逻辑，把人们从繁重的重复性人工处理中解放出来，去做更有创造力和乐趣的工作。特别是在 20 世纪 80 年代以苹果电脑和 IBM PC 为代表的个人电脑的出现后，计算机迅速普及到了各行各业。
计算机之所以很有用，是因为通过使用计算机软件能够解决人们所从事的某个领域的问题。然而，假如软件的开发人员并没有深入理解软件所处的领域，软件就无法很好地解决该领域的问题，其实用价值就会大打折扣。因此对于业务软件的开发人员，应该时常提醒自己的一句话是：“笨蛋，问题是领域”。深入理解领域的开发人员，即使使用过时技术所开发出来的软件，也远远好过完全不理解领域的开发人员，使用最时髦技术所开发出来的软件。
遗憾的是，这个很明显的道理，在软件开发人员中并没有被普遍接受。在很多兴趣驱动的开发人员看来，深入理解领域中的业务逻辑，是一件枯燥乏味的事情。他首先会考虑：“我要在这个项目中使用苹果公司新推出的 Swift 编程语言，在服务器端要使用 Hadoop，最好再尝试一下深度学习方面的技术”，然后就一头扎进这些时髦和高大上的技术之中。三个月后，你去问他需要解决的领域中的真实问题是什么，他还是一脸茫然。
哥们，别王顾左右而言他，作为软件开发人员，很可能你也有这样的倾向。实话实说，在大约十年前，笔者也曾经是这样一位兴趣驱动的开发人员。当然，责任并不是完全在我身上。IT 行业，尤其是软件开发行业，是一个非常喜欢炒作新概念的行业。新的编程语言、新的开发框架层出不穷，让开发人员疲于跟随。以有涯之人生，去追随无涯的技术变迁，实在是一件很痛苦的事情。
如何跳出这样的恶性循环，获得人生的解脱呢？我们需要有某种方法论的指导。幸运的是，这种方法论已经有了，那就是领域驱动设计——DDD。DDD 就是我们做业务软件开发的指路明灯。它指导我们专注于最重要的问题——领域，并且为如何设计好的领域模型，以便更好地解决领域问题提出了很多具体的做法。
DDD 并不是突然冒出来的天生石猴，它其实是 30 年来业务软件开发（不同于科学计算类软件）实践经验的结晶。在笔者看来，它的起源甚至可以追溯到将近 40 年前的《人月神话》这本经典名著（你还没有读过？那你出门可不大好意思跟别人打招呼啊）。在《人月神话》中，布鲁克斯老先生将维护软件的“概念完整性”作为软件开发的核心问题。软件之所以很复杂、难以维护，根本原因就在于软件的概念完整性遭到了破坏，甚至开发团队的成员从来就没有意识到有必要去维护软件的概念完整性，他们并不是一个真正的团队，只是一些自行其事的开发人员，碰巧在一个团队中一起堆代码而已。
在项目开发最初的时候，他也有过一段狂欢般的快乐时光，不久之后，事情就越来越艰难。项目的代码越来越难以维护，工作越来越像是一种煎熬，合作的同事对他越来越不满。“该是与这个项目，与这个公司说 bye bye 的时候了”，他想。他换了一家公司，涨了一点工资，开始了另一段狂欢。周而复始，一年又一年过去了。随着年龄的增长，他不再能够从软件开发中享受到乐趣，软件开发的职业生涯，对于他而言痛苦多于快乐。学习新的技术，他也比不上年轻人。运气好的话，他可以完全脱离开发，转去做管理、做产品设计、做业务，运气不好的话，他只得继续做开发，因为毕竟还要养家糊口。“继续混着呗”，他悲观地想。他从一家公司换到另一家公司，从一次失败，走向另一次失败，他始终都是一个 loser。
上面这段描述，其实就是目前国内大多数软件开发人员的真实写照。对于缺乏学习能力的开发人员而言，从事软件开发的职业前景是灰暗的，最终他们会被这个行业所抛弃。想想看，国内目前的软件开发人员有几百万人，还会有越来越多的年轻人加入到这个行业，如果他们只能无奈地走上这样一条不归路，这可真是一个严重的社会问题。
在笔者所在的公司里面，有一个很重要的项目，最初的架构师（不止一个人）在错误的架构设计风潮的影响下，决意把这个项目设计成一个全分布式的系统。他们设计了十几个分布式服务，相互之间通过 WebService 通信。他们还引入了一个开源的 ESB（企业服务总线）中间件——Mule。项目开发的鼎盛时期，曾经有二十几个开发人员，每个人负责开发不同的分布式服务。因为架构师对这些程序员缺乏必要的指导和控制，每个程序员只熟悉自己负责的一小块工作，相互之间缺乏沟通和协作。这个项目的概念完整性很快就遭到了破坏，架构师所画的架构图，在代码实现中消失了。程序员很快就不再关心最初画的那些架构图，他们开始自行其事，只求尽快完成手头的工作早点下班。十几个分布式服务所导致的大量远程调用给系统的性能和可伸缩性带来了巨大损失，每一个远程调用都有可能出错，全部可能出现的异常情况难以计数，极大增加了异常处理的开发和测试工作量。同时给配管、运维人员的发布工作也带来了巨大的困难，每一次的上线发布都像是一次艰难的战役。Mule 这个中间件，并不适用于大流量互联网应用的环境，其性能和可伸缩性有很大的问题。最初引入 Mule 时，架构师甚至都没有想到应该提前做一些压力测试！项目的开发人员，离职的越来越多，也包括最初的架构师，最后只剩下了 4 个人。这么少的人很难维护十几个分布式服务，架构师只好决定将 Mule 完全废弃掉，将十几个分布式服务合并为三个相对独立的集中式应用，将远程调用改为了本地方法调用。这样做起码配管、运维人员的工作能够大幅减少。然而，这种合并仅仅是把代码简单地合在一起，原先因为存在十几个分布式应用，程序员自行其事，所导致概念完整性遭受的破坏，仍然完全没有解决，因此这个项目的代码仍然难以维护。这真是一个 design by buzzword 的典型案例，软件开发的很多反模式都可以在这个项目中找到。这个项目的开发人员流动性很大，一个重要原因是他们无法从这个项目中获得开发的乐趣。
那么，这个项目就完全无药可治了，只能等待寿终正寝了吗？答案是并非如此，只要下定决心，坚持正确的工作方法，在完善自动化验收测试的前提下，对项目代码进行持续的重构和改造，提炼出良好的领域模型，这个项目仍然有恢复健康的可能性。当然，改造工作的重要性和所需要投入的成本，也需要得到公司管理者的认可和支持。
代码的质量如果不加以控制，就一定会迅速腐烂变质。这是一个客观规律，就像在热力学第三定律中，熵总是会增加一样。对于软件开发而言，“概念完整性”就相当于热力学第三定律中的熵，是衡量软件项目混乱程度的重要指标。DDD 就是目前维护软件项目“概念完整性”的最佳良药，虽然永远不可能出现某种银弹式的技术，但是 DDD 能够很好地解决软件开发中的这个核心问题。DDD 与重构技术（参见 Martin Fowler 的《重构: 改善既有代码的设计》）都有助于改善代码的概念完整性，但是它们有不同的定位。重构是在代码实现层面对抗腐烂变质，而 DDD 是在代码架构设计层面对抗腐烂变质，两者是互补的关系。实践 DDD，能够控制好软件开发的复杂性，最终交付令用户感到满意的业务软件。
DDD 创造者 Eric Evans 大师的经典著作《领域驱动设计——软件核心复杂性应对之道》，对于初学者而言还是很抽象的。InfoQ 几年前出版的 Domain-Driven Design Quickly（dddquickly）是一本 DDD 方面非常棒的入门书。因为工作需要，笔者有强烈的愿望想要把 DDD 介绍给合作的同事们。然而，dddquickly 之前的中文版的质量不大令人满意。因此笔者决定在之前中文版的基础上，重新翻译 dddquickly 这本书。笔者的老朋友，dddquickly 之前中文版的译者 Kevin Huo 对这个工作给予了大力支持。笔者和 Kevin，还有 InfoQ 中文站的编辑马国耀、丁雪丰，都有强烈的愿望，希望 DDD 能在中国尽快普及，生根发芽、开花结果。这个工作很有意义，这是一次非常愉快的合作。建议读者从阅读 dddquickly 中文版入门，然后再去坚持读完 Evans 大师的原著，相信可以取得张无忌修炼九阳神功之后的效果。
正如对 Evans 的访谈中 Evans 所说的，对于业务开发人员而言，衡量一种技术好坏的最终标准，应该是这种技术是否有助于开发人员专注于研究领域问题。任何会导致开发人员分心的技术，哪怕这种技术再高大上，在项目开发中也应该坚决抛弃。学习新的技术很重要，但是专注于研究领域问题更为重要。只有更好地解决用户真正关心的领域问题，软件开发人员才能获得职业生涯的长青。
李锟
2014 年 11 月 8 日
评论 (3 条评论)