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一样。