贫血的Domain Model

先不说你多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层吗？

从简单设计和重构的角度来看。最开始，应该是直接在action中调用domain。后来发现，需要抽出一个方法来调用domain，然后这个方法提供一个服务，支持action。后来发现，这个方法还需要一些额外的依赖和更多的实现内容，于是抽取出一个接口，注入一个对象到action中。后来发现，很多地方都需要这么做，那么就强制要求action必须依赖于service的接口，不能直接访问domain对象。这么一组抽象的接口，就构成了一个service层。

您还真说对了，实际中就是用的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我是实在不了解，抱歉了。

Linq 不是也有Linq to Objects嘛！ 这个应该和DLinq有异曲同工之效

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

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

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

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

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


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

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

似乎你说的service和我说的还不大一样，呵呵。

DomainObject之间的交互是不需要Service的。

sorry 看到这个较晚，
大致回复下:

我们的系统有很多模块组成， 各模块基本上通过数据库来共享信息。
主要的模块大致有： 核心系统（非web）， 网站、 bbs、 网站后台，核心系统后台，BI， 推广员等等

原来的打算是写个rich domain model供各模块来使用，以便代码重用减轻个模块开发的工作量

一个简单的例子， User 原有 changePassword, getFriends, addFriend ... 等等方法
撇开配置以及获取User对象的复杂性不谈， 实际开发中发现， 这些东西重用的地方太少了，
对网站来说很好的rich domain model， 在网站后台里面就麻烦，很多方法在那里根本就是对后台
开发人员的干扰，而很多方法对核心系统、BI等等根本就毫无用处。
而且由于网站之类的web系统， 其功能变化很快， 今天一个样子明天完全有可能是另外一个样子了，
新招个策划都可能提出一堆的改动来， 还有很多临时性的功能， 最后真正在各模块之间共享
的就是最贫血的domain model， 基本上就是表的映射， 连关联都给废了各处自行维护了

因为系统数据量比较大，所以性能问题也受到比较多的关注， 在系统的关键部分， DBA说了算，OO靠边站

实际上我在几个公司呆过 也曾试图写出比较rich的domain model， 但是只要项目的需求变更的比较频繁，
那么rich domain model维护的成本就会很高， 而且想重用的想优雅的地方最终大部分变成了摆设，
而需求变更不频繁的项目， 太少太少了

看了这么久的领域模型，争论的真是没完没了。
难道就不能跳开这个领域模型或者还领域模型一个真正的身份，不要在贫血充血的来讨论了。