一个简单例子：贫血模型or领域模型

对于业务逻辑复杂一些的大项目，领域模型很有必要，但是需要项目组有个有经验、有技术的 Leader。许多做了很多年的 Java 程序员也不知道什么是贫血模型，什么是领域模型。对于 DAO 和 Repository 的区别，我还是不太明白，还要到看看 DDD 那本书。

第一个问题，重构能够解决部分问题，但不能解决全部问题。我承认对于这个简单的转账例子，如果添加取钱和存钱服务，一个优秀的程序员完全能够提取方 法重构来消除代码上的重复，但是请注意，这只是技术上的手段，不是领域的驱动。我曾经参加的一个项目，当我查看现有代码时，发现里面很多重复代码，由于看 完《重构》不久，十分想练手，SDM也赞同，于是让我做code review。刚开始很兴奋，但是当消除几个明显的代码重复之后，剩下来的工作越来越举步维艰，很多逻辑相互交织在一起。虽然明显看到其中存在重复，但是 却很难使用提取方法来重构，好几次还不得不回复成原来的代码，因为重构后的方法和原来的代码存在细微的不一致。提取后的方法很少具有业务意义，它只是技术 上的手段，因此也并有因为重复代码的消除而获得更可理解的代码。对于这种过程化的类，我发现几乎仅有的重构手段就是提取方法，不管是提取到当前类，还是提 取到一个外部的工具类。最终的结果是，我的重构实质上并没有带来实质性的好处。我认为，重构需要有领域模型的引导，否则它可能走错方向。

 

第二个问题，你认为WebUI和WebService接口的Service代码能够重用吗？两者接口的粒度不同，这会导致它们使用的DTO完全不 同，要想重用几乎是不可能的。关于我谈到的领域模型的缺点，我坦率的承认实施领域模型有很大的风险，尤其当项目中没有一个人真正懂得领域模型时候。

一：
我也认为DAO是有必要的，
毕竟DAO干的那些是和业务逻辑是没有关系的。
为什么要业务逻辑混在一起啦，
而且如果以后数据持久话发生了变化，不是领域模型都要受到影响，
我认为，只是业务逻辑发生变化，才有修改领域模型对象的必要。

二：
还有，我认为在领域模型里面的那些setXXX和getXXX和业务逻辑的方法混在一起的确不是个好注意。我的观点是领域模型里面Public一个Pojo，让那些getXXX，setXXX通过哪个Pojo去做，领域模型的方法就是业务逻辑方法和持久化方法（通过委派到领域模型的DAO的方法）
这样 领域模型= pojo + Dao + 业务逻辑方法和持久化方法

service 也就是调用多个领域模型，其实service要做的就是通过那几个领域模型来实现一个用例