DDD思考之四 不要买椟还珠

最近比较忙，陆陆续续才把DDD的书看完，自己的一个Demo也没有时间深化下去作，用的是我最鄙视的“learning without practise”方法。

不过这也是有情可原的，因为这本书后面大部分讲的都是方法论的东西，实际上，一共16章，只有前面7章说的是被热议的Entity/VO/Repository/Factory等实践，后面的篇幅都在讲项目中如何维护Domain的可用、可理解、可维护。这些原本就没法在一个简单的demo中实践。

通观全书，在Evans的DDD中，用什么方式构建Domain属于“术”的范围，而如何在项目的生命周期中维护Domain才是“道”。术，容易在Demo中体现，也容易搭个框架，引进几个interface和abstract class来实现；由于这些东西是业务无关的，所以容易在程序员讨论中引起共鸣，也才会有那么多人热衷于讨论DDD和OR-mapping的关系，entity是不是可以应该访问repository等问题。而“道”是指如何抽象，维护 core domain，如何让core domain和 subdomain，其他团队乃至其他系统的交互更自然，更实际。这就很考业务了：只有对业务有正确的理解，才能引导domain expert通过纷繁复杂的描述，提取出domain乃至 core domain；只有对业务的未来发展有正确的预期，才能评估每一个功能应该放在系统的什么位置。

后半部分的“道”在mini book中完全没有提到，不知道编者出于什么考虑。实际上单就实现而言，DDD的这些概念相对于传统的贫血模型和DAO也许更“美”一些，但未必就能吸引项目组去使用。只有把眼光放到项目的整个生命周期中，DDD所倡导的自描述模型，通用语言才能显示出其优点。换句话说，对于3个月的小外包，看不出DDD的必要。但一个500强要用上10年的核心系统，DDD（用的好的话）就能体现出其优势了。而所谓的道，讲的也就是这样的系统演化过程中如何取舍和维护。

所以，如果只看mini book和 ddd sample，对于DDD真是买椟还珠了。DDD不仅仅是充血模型，正如EJB不仅仅是session bean一样。

评论

4 楼 iamlotus 2011-04-25  

好吧，我想我已经明白你的意思。
你的意见我基本都同意，尤其是关于DDD(也包括TDD)的人员要求，他们原本就不是为了让靠在SSH上拼SQL的人用的。
不过用户啥都不管也是有的，如果你做过政府的工程就知道了。

3 楼 redhat 2011-04-25  

iamlotus 写道

项目什么时候会“面向OOP高端人才”了？ 项目都是客户导向的，客户管你是DDD,TDD还是什么DD，能按时按量提交就行。尤其是小外包，钱货两清，你连领域专家的面的见不到，还谈什么领域？难道你认为领域是从外包文档里读出来的？

我感兴趣的是这“一个月能搞完的项目”中间有多少和领域专家的交互，有多少在交互中发现已有模型的不足,有多少针对这些不足进行重构，最后精炼的模型和一开始的理解有多大的差距。你能说一下吗？

不管是XP还是DDD，都是Agile的一种实现，都强调用户/领域专家的参与，当然用户和领域专家的参与是有区别的。用户在一定时间内要东西出来，完全是正确的，但是用户想在开发过程中跟个傻子一样啥也不管，啥也不知道，这样的用户我至今没有碰到，不知道你碰到了几个。用户！=一个用户经理一时的冲动不能完全表达意思的几句话。 这也是为什么“难道你认为领域是从外包文档里读出来的”，这个你完全不知道这样和领域专家与用户打交道，消化知识中，就告诉你，没有明显的完整的领域模型摆在你没钱，你读两下文档就懂了领域，除非你在这个领域已经很多年了。

不管你感兴趣的是一个月搞完项目还是半年搞完项目，你的团队完全由低级的，只会使用函数，不会设计，没有抽象能力的人员，那么使用DDD不可能完成的。如果你的人员OOP能力很强，对于复杂项目（不一定化的时间多，但是你们一个月的项目），DDD都是上选。我曾经做一个很简单的项目，别人两个人2个月没解决的问题，我花了4天把它搞定，这个从时间上不恩能说明任何问题。

做项目，不能臆想用户怎么变态/怎么不合理，只会要求你们一天内把1年的事干完了，我至少没有碰到，碰到的最多的是我们开发人员昂着高傲的头告诉用户，这个我们设计/后台/框架就是这样，你们的需求我们没办法完成，这是一种侮辱。

2 楼 iamlotus 2011-04-25  

redhat 写道

“对于3个月的小外包，看不出DDD的必要。”
不同意你的说法，这个主要与人员的素质和领域的复杂度有很大关系，如果你想面向低端会使用函数的编程人员，不管项目大小，都是用贫血比较容易理解，如果你的项目想面向OOP高端人才，建议你使用DDD，不管项目大小。
我做了一个项目，核心我写了3天，后来加上维护一共一个月，当然构建这个我们之前做准备大概2-3个月。现在回想起来，没有DDD和OOP，就不可能在那么短时间完成它。
另外，那本书相关章节我看了3-4遍，不管哪一遍下来，我从来不觉得它是讲“Entity/VO/Repository/Factory等实践”。我的心得是，它是讲如何消化领域知识，如何根据消化构建出精炼的模型，并注意中间的风险（要联系实现技术等，大型系统模型维护问题），解决复杂领域的问题。

项目什么时候会“面向OOP高端人才”了？ 项目都是客户导向的，客户管你是DDD,TDD还是什么DD，能按时按量提交就行。尤其是小外包，钱货两清，你连领域专家的面的见不到，还谈什么领域？难道你认为领域是从外包文档里读出来的？

我感兴趣的是这“一个月能搞完的项目”中间有多少和领域专家的交互，有多少在交互中发现已有模型的不足,有多少针对这些不足进行重构，最后精炼的模型和一开始的理解有多大的差距。你能说一下吗？

1 楼 redhat 2011-04-23  

“对于3个月的小外包，看不出DDD的必要。”
不同意你的说法，这个主要与人员的素质和领域的复杂度有很大关系，如果你想面向低端会使用函数的编程人员，不管项目大小，都是用贫血比较容易理解，如果你的项目想面向OOP高端人才，建议你使用DDD，不管项目大小。
我做了一个项目，核心我写了3天，后来加上维护一共一个月，当然构建这个我们之前做准备大概2-3个月。现在回想起来，没有DDD和OOP，就不可能在那么短时间完成它。
另外，那本书相关章节我看了3-4遍，不管哪一遍下来，我从来不觉得它是讲“Entity/VO/Repository/Factory等实践”。我的心得是，它是讲如何消化领域知识，如何根据消化构建出精炼的模型，并注意中间的风险（要联系实现技术等，大型系统模型维护问题），解决复杂领域的问题。