贫血的Domain Model
好老的话题啦。拿出来炒炒冷饭。各位见谅。
——————————————————————
Domain Model贫血是说属于Domain Model的逻辑没有放在Domain Model中。那是哪些逻辑没有放到Domain Model中，从而导致贫血一说呢？原因有很多，但是我认为最主要是Service中的那些逻辑。而这些逻辑又有一个共同的特点就是依赖于DAO，或者说需要查询数据库。Robbin的帖子：http://www.iteye.com/topic/57075，举了一个很好的例子。我取其中的一个部分在这里做演示用。
通过指定RichEntityTuplizer，我们可以控制Hibernate的动态增强过程。
大家的做法不某而和，呵呵。
如果做过多Client的WebServer项目的话就不会有太多疑问了。
这种项目中，web层本身只不过是众多client中的一个而已，另外还有GUI的 或 独立进程（用于系统间通信）的client，这些client并不能直接使用webserver里面的DomainObject，必须要一个Service／action层作agent，其实service层也可以发展成应用／界面逻辑（顺便控制事务边界），而Domain中是真正的领域相关的业务逻辑。 大家的做法不某而和，呵呵。
如果做过多Client的WebServer项目的话就不会有太多疑问了。
这种项目中，web层本身只不过是众多client中的一个而已，另外还有GUI的 或 独立进程（用于系统间通信）的client，这些client并不能直接使用webserver里面的DomainObject，必须要一个Service／action层作agent，其实service层也可以发展成应用／界面逻辑（顺便控制事务边界），而Domain中是真正的领域相关的业务逻辑。
先不说你多client的项目是多么的罕见，就算你有GUI的独立client，你用什么方式和Server通信？说到底无非就是两种：
1、RMI方式
EJB就是基于RMI方式，但我相信你不会采用RMI方式，RMI不但复杂而且有太多限制，现在这种方式已经基本不被采用了
2、Web Service方式
好吧，Web Service方式你是不是还是需要Server端有一个Web层？
所以不管你是不是多个client？ Server端必然都是通过Web层提供服务的，所不同的只不过是client是浏览器、手机、或者应用程序而已。所以Service层真的是必要的吗？恐怕未必吧。
你就看Rails的REST，人家只有Web层，那有怎样？ 看看twitter吧，浏览器访问、手机访问、桌面软件访问、插件访问，其他网站API访问，消息访问，这client够多了吧，可是Rails需要什么Service层，什么agent层吗？
大家的做法不某而和，呵呵。
如果做过多Client的WebServer项目的话就不会有太多疑问了。
这种项目中，web层本身只不过是众多client中的一个而已，另外还有GUI的 或 独立进程（用于系统间通信）的client，这些client并不能直接使用webserver里面的DomainObject，必须要一个Service／action层作agent，其实service层也可以发展成应用／界面逻辑（顺便控制事务边界），而Domain中是真正的领域相关的业务逻辑。
先不说你多client的项目是多么的罕见，就算你有GUI的独立client，你用什么方式和Server通信？说到底无非就是两种：
1、RMI方式
EJB就是基于RMI方式，但我相信你不会采用RMI方式，RMI不但复杂而且有太多限制，现在这种方式已经基本不被采用了
2、Web Service方式
好吧，Web Service方式你是不是还是需要Server端有一个Web层？
所以不管你是不是多个client？ Server端必然都是通过Web层提供服务的，所不同的只不过是client是浏览器、手机、或者应用程序而已。所以Service层真的是必要的吗？恐怕未必吧。
你就看Rails的REST，人家只有Web层，那有怎样？ 看看twitter吧，浏览器访问、手机访问、桌面软件访问、插件访问，其他网站API访问，消息访问，这client够多了吧，可是Rails需要什么Service层，什么agent层吗？
您还真说对了，实际中就是用的RMI，还就因为这个使用了SLSB（当然web可以走近道local）。
04年的项目了，现在要赶时髦当然可以换成HttpInvoker、Hessian、Buriap、甚至JSON......
不过慢着，如果当时将应用逻辑混合到了SLSB里面（而没有将其分离到独立的service层，这个就和你认同的将逻辑写到web的action里面一样），哦，我的天，恐怕这事儿还真麻烦了......
另：
我相信没人真的喜欢webservice，
不过即使是使用webservice，webservice也只是一个adapter而已（不含任何业务），同样SLSB也只是提供RMI的adaper，这些adapter都只是技术相关的，他们本身不能算作一个层，但他们却都需要使用service层来完成动作。
从ROR看REST的神奇之处在于，他将REST（系统间的接口）和正常的Web应用（人机接口）较完美的和谐成一套代码了。再加上ROR本来就没有分层，只有MVC。而JEE是强调分层，然后再在Web层使用MVC。在Rails里面别说找什么Service层，agent层，你连表现层，逻辑层，持久层都找不到。。。差异太大，先别参考了。
twitter我是实在不了解，抱歉了。
public class Employee { @OneToMany private Set<Task> tasks = new HashSet<Task>(); public Set<Task> getProcessingTask() { ...... } public static getAllEmployee() { ...... }}
如果当时将应用逻辑混合到了SLSB里面（而没有将其分离到独立的service层，这个就和你认同的将逻辑写到web的action里面一样），哦，我的天，恐怕这事儿还真麻烦了......