ddd quickly 中文版译者序

在去北京参加infoq大会之前，我就开始了对DDDQuickly的翻译工作，如今，在我和 泰稳的努力下，它终于可以跟大家见面了。我心甚慰。

可以去 infoq中文站免费获得此 迷你书。

 

======================================

 

序言

在2004年之前的某一天，我跟所在部门的一个设计师进行沟通，当时他为自己的一个思路兴奋不已，而我要做的事情就是跟他讨论清楚他头脑中的那个想法，然后写出需求和设计文件来。大家可能会注意到，很多时候，需求是从设计中反推出来的，这被一些专家称为“需求的反向工程”。其实我更多地认为这是由于我们现在糟糕的工作现状决定的，有诸多的因素导致需求或者设计被局限在仅有的几个人的知识体系中，但如果有心去细察，会发现他们各自的理解又各不相同。

回到刚才说到的那次沟通上，当那个设计师把自己的得意之作描述完毕后，我在纸上用UML图画出了他的主题思路，然后我们针对细节开始探讨并在图上改改画画。最后的修订结果显示，他的很多"创举"是多余的，经过精简后的UML基本上颠覆了他原有的思路。现在我还记得那位同事的一声叹息："一周的功夫白费了……"

其实在整件事情中，他有他的得失，我也有我的收获和困惑：我意识到对统一的核心模型进行探讨和简化的重要性，但应该如何把这样的过程程式化，让它在更多的同事的工作中发挥作用呢？

这样的问题纠缠了我好久，终于有一天，我得到了一本如字典般的硬皮《Domain-Driven  Design》（我们亲切地称它为"DDD"）原版书，从中找到了答案。然后，我参与了DDD中文版的审校工作和DDD注释版的注释工作。再后来，InfoQ中文站的总编霍泰稳又邀请我一起做了《Domain Driven Design quickly》这本书的翻译工作。

曾经有人要我用简练的词汇描述DDD的中心思想，我个人认为这是一个比较难的工作，但我愿意去尝试。我的回答是"关注精简的业务模型及实现的匹配"：

1. 如果你了解"模型"的定义是对现实的有选择性的精简，然后用这样的观点去读DDD这本书，你就会发现，DDD其实没有什么太多的新鲜玩意，它更多地是可以看作是面向对象思潮的回归和升华。在一个"万事万物皆对象"的世界里，哪些对象是对我们的系统有用的？哪些是对我们拟建系统没有用处的？我们应该如何保证我们选取的模型对象恰好够用？

2. 前面的选择性问题只是解决了一个初步框选的问题，对象并不是独立存在的，它们之间有着千丝万缕的联系。这种扯不断理还乱的联系构成了系统的复杂性。一个具体的体现就是，我们修改了一处变更，结果引发了一系列的连锁反应。虽然对象的封装机制可以帮我们解决一部分问题，但那只是有限的一部分。我们应该如何在一个更高点的层次上，通过保留对象之间有用的关系去除无用的关系，并且限定变更影响的范围以来降低系统的复杂度呢？

3. 在DDD以及传统OO的观点中，业务而不是技术是一个开发团队首先要关注的内容，众多的框架和平台产品也在宣称把开发人员解放出来，让他们有更多的精力去关注业务。但是，当我们真正去看待时，会发现，开发人员大多还是沉溺于技术中，对业务的理解和深入付出的太少太少。其实要解决这个问题，就要先看清楚我们提炼出来的模型,在整个架构和整个开发过程中所处的位置和地位。我们经常听到两个词，一个是MDD（模型驱动设计）,一个是MDA（模型驱动架构）。如果DDD特别关注的是"M"(以及其实现)，那么，这个M应该如何与架构和开发过程相融合呢？我经常会看到我们辛苦提取出来的领域模型被肢解后，分散到系统的若干角落。这真是一件可怕的事情，因为一旦形成了"人脑拼图"，就很难再有一个人将它们一一复原，除非这个人是个天才。

4. 很多面向对象的教材，都会告诉你若干的技巧，让你去机械化地处理模型和对象实现，但是这些教材通常会忽略一个大的上下文环境，就是应该由哪些具有什么样素质和技能的人来处理模型和对象实现,或者说白了，就是应该用什么样的团队模型来匹配业务模型。不同的模型，需要不同的团队模型的支撑，不同的团队模型也会让一个模型实现更优秀或者更糟糕。

5. 相信很多人读过ATM机的例子，你发现自己彻底明白了用例应该怎么编写、模型怎么提取和实现，但是当你信心十足地去开始你自己的项目时，你又会发现你的思路片段化了，所有你明白了的技能在你的新项目中好像用不上。算了，还是老的工作思路和工作方式比较顺手，于是一切都照旧会到了老的套路上。那么，面向对象技术或者说我们提炼出来的模型应该如何在大型项目/团队中使用呢？我们是应该要求一个项目使用统一的模型，还是应该把它们分成不同的模型？我们应该如何抉择？

……

在实际的应用过程中，我相信每一个有心人都会提出比我在这里列举出来的还要多的问题，没有关系，DDD这本书都能给你所需的答案。

当然，"DDD"作为传统OO范型的探索和升华版，也存在着一些不足和未涉及的领域，例如：在安全、权限方面的考虑，其基本构造块的适用范围和决策标准，与开发框架之间更好的融合性等问题。还好，我们都知道"尽信书不如无书"的道理，在阅读任何著作时，都应该带着自己的疑惑和批判精神去阅读，你的任何关于DDD的深层思考和讨论，都可以在它的配套网站或者InfoQ中文站网站中发表。

如果你认为阅读DDD这么一本如字典版的大厚书时间上不太允许，那么请允许我为你介绍一本简化版的小书《Domain Driven Design Quickly》，经过我们的努力，InfoQ中文站已经将其翻译成中文版——《领域驱动设计精简版》，并作为国庆礼物奉献给大家！

那还等什么呢，祝您开卷有益，阅读愉快！

孙向晖

2007年9月26日于泰安