领域模型的价值与困境

我来说几句吧：

所以最终我对这个问题的总结就是：

一、只要技术框架能够实现，尽量使用领域模型

二、无论Java还是Ruby，必须消灭DAO和TransactionScript

三、领域模型不必All-in-One，Java可以分割为 1个entity bean和几个business bean，而Ruby可以分割为1个model和几个mixin的module。

我来说几句吧：

第一、DAO层和TransactionScript层是邪恶的！

我们在2004年一直跨度到2007年讨论来讨论去，其实都有一个隐含的前提条件：你的领域模型终究无法脱离对DAO层的依赖，以及需要TransactionScript层的包裹。而这样一来，领域模型的通用性、可移植性、业务逻辑的表达能力基本全部丧失，沦为框架限制下的奴隶。

而我们看看现在Java领域的技术进步，JPA已经普及，EJB3的隐含事务管理，甚至连Spring也可以简化成@Transactional，现在已经是我们可以去掉DAO和TransactionScript的时代了。


第二、Seam在消除了DAO层和TransactionScript以后，领域模型的感觉已经呼之欲出

这个不用多说，大家自己去看Seam文档好了。我唯一想强调的是entity bean和business bean分开有没有必要性，我的看法是有必要！这还是和Java本身语言的限制有关系：

1、Java语法表达能力有限，entity bean又不得不弄一大堆getter/setter方法，都放在一个class里面，代码的可阅读性非常差

2、business bean的很多业务逻辑方法需要容器环境，不像Rails的model可以直接mixin进来

3、Java做为目前最主流的工业语言，开发团队都是大规模编码协作的，你都放在一个class里面，团队协作会遇到很大的麻烦(事实上RoR现在也有这样的问题，但是RoR开发效率高，往往不需要那么大规模的开发团队)

3、领域模型不同类别的业务逻辑可以很容易的分到几个不同的business bean里面，这样对团队协作的好处很大。


第三、不考虑框架限制，All-in-One的领域模型好不好？

比方说RoR的model就是All-in-One的，但是一旦出现可以抽象出来，比较通用的业务逻辑，我们还是会把这些逻辑抽出来，单独实现，然后再mixin回去。


所以最终我对这个问题的总结就是：

一、只要技术框架能够实现，尽量使用领域模型

二、无论Java还是Ruby，必须消灭DAO和TransactionScript

三、领域模型不必All-in-One，Java可以分割为 1个entity bean和几个business bean，而Ruby可以分割为1个model和几个mixin的module。

但是一旦有了DistributionDao，就不一样了。

distributionDao.save(new Distribution(somePublication));

哈哈，啥控制都管不了我了吧。很多时候Dao就是这么无法无天的。如果说domain model是数据的防火墙，那么dao就是顶级黑客。由于Entity不能注入等实现和宗教信仰上的限制，往往导致了service对DAO的滥用，就会造成上面这样的by-pass domain model的情况。

数据和行为距离很远。造成了不容易理解数据含义，因为你光看entity压根不知道它会被怎么用。漏掉一些servie中细微的用法，就可能会造成很大的bug。
同时这也更加让可重用的逻辑更难被发现，从一定程度上鼓励了大家各自发明，一份逻辑写n遍，还n遍都不一样。。。

有人说DAO可以屏蔽数据库的底层实现细节,让程序代码能够在不同数据库之间切换,这是很难做到的,一般情况下DAO只是出于不重复造轮子来封装一些数据库级别的操作,并且业务开发人员不必去操作RS,SQLException这样的数据库级别对象而已,至于屏蔽数据库差异,但凡是某个接口可以输入整句sql,开发人员就有可能传入只有某个数据库才能运行的语句,所以除非能让开发人员彻底不需要写sql(Hibernate这样),屏蔽数据库差异是不可能的.