贫血的Domain Model

domain是不应该太贫血，但也没必要单纯为了rich domain而取消service层。

假设取消掉service层：
首要问题就是domain之间的交叉依赖，而在传统service层中，domain之间的关系从来都是交给具体service去完成的，service搞的再烂，也不会把domain搞烂；

然后是事务边界带来的bad smell（虽然将持久化设备注入给domain也不见得是坏事，但习惯上总觉得不那么好）

然后是如何为prototype bean进行注入；

最后还有诸如团队协作这样的麻烦，逻辑过于集中后，协同开发的确成为了麻烦事情。


所有这一切，只换来一个“逻辑集中”的优势，不用再考虑哪些方法该调用domain的，哪些是service的。而这些完全可以被合理的方法命名和编程规范所解决。

取消service层追求完全的rich domain，实在是弊大于利。

to coolnight：能不能举一个你们公司的Rich Domain Model的例子，以及它们是如何被大家废弃的。

java里面使用静态方法的不便之处很多， 比如说不容易扩展， 不容易被替换等等，而ruby的特性决定了这些不是很大的问题。java里面这种形式的rich domain model的事务也不容易被管理
在java里面用ioc来管理依赖是比较好的做法， 很难扔掉；而且 ioc也确实带来很多的好处

一个复杂的系统里面，真正最稳定最一致的东西是什么呢， 其实正是那些 贫血的domain model！

除非需求非常明确， 系统在设计期就能定下rich domain model，最好对于独立的model很少有团队协作，这种
情况下rich domain model才有优势， 至少少了一个dao的依赖。 但是这样严格的场景太罕见了，
大部分情况下需求经常在变， 经常要加上新的功能， 这个时候就会发现，如果是rich domain model的设计，
对domain model的不断的修改就成了一个梦魇！ 如果有多人协作完成系统的不同部分，互相之间要share domain
model的时候， 那rich domain model就更加难以运用了！ 如果还要用Service层进行事务管理的话，那很多时候
就必须把rich domain model里面的功能在Service层全都包装一遍， 那么为什么不直接在Service层直接实现
rich domain model的功能呢？

我们公司现在的产品就是这样， 开始的时候就是贫血domain model和rich domain model都有， 越用就越发现贫血模型的好处。现在 rich domain model的功能大部分处于废弃状态， 真正有用的，基本就是 贫血 domain model, 或者说po,
加上一个薄薄的dao层， 然后系统的各个部分各自使用各自的service层，很清晰很简单很有效!!

public class Employee {  
     @OneToMany  
     private Set<Task> tasks = new HashSet<Task>();  
     public Set<Task> getProcessingTask() {  
        ......
     }  
     public static getAllEmployee() {
        ......
     }
} 

比方说类似这样的，如果不依赖特定对象实例的方法，直接用静态方法如何？如果getProcessingTask用到其他对象的方法，如果是依赖对象状态，可能就是方法参数传递进去，如果不依赖，直接调用该对象静态方法。

不知道这样去用，会不会有什么问题。自从IoC兴起以后，貌似就没有人这样去用了，大家都极力避免静态方法的出现。