浅谈Domain Model和Domain Service

 1.今天在学习项目的架构时发现项目的业务层,除了用ejb外还加入了domain,一时不能理解,感觉业务用ejb处理不就完了吗??还引入domain作什么用啊?这样就在网上开始搜索相关信息,终于在一位网友的博客上找到了一丝线索

(http://www.blogjava.net/AndersLin/archive/2006/06/15/53086.html)

网友问
 在他的博客里有一位网友问倒了这两者之间的区别?
 作者答1:
Domain Object关心的是自己，只处理和自己状态有关的逻辑。
Domain Service则处理Domain Object之间的关系，以及Domain Object和外部的交互。
比如一个party无法维护更新自己的hierachy，因为需要和其它的party相关；
再比如一个party无法维护更新自己的role
作者后又补充:
 如果说client（如web request）是一个业务操作的发起者，那么Domain Service是一个业务操作的实施者，Domain Object是一个业务状态的承受者。
或者更简单的说是一个调用与被调用的关系

我觉得
不过我看了后还是不很明白!看来还得慢慢理解拉!
我感觉,domain就是将一些复杂业务进行了抽取,没有将其直接在ejb中实现,也是为了代码的可读性和可维护性.
2.哈哈...又找到点信息这回这个可能要好点的!
引自: http://cpccc.blogdriver.com/cpccc/146705.html

今天读了Mark Eagle的Wiring Your Web Application with Open Source Java
文中介绍的open source方案，
表现层采用了struts，持久层采用了hibernate，中间件业务层采用了Spring容器。
可以说在技术上是很先进的。
读完全文，对于Spring，又有了一个新的认识。
确实正如Rod Johnson说的，Spring没有重复制造轮子，它提供的这种组件容器的功能把各种有用的framework结合了起来。
提供了软总线的功能，充分利用了面向接口编程，大大降低了各个层次之间的耦合。

比较让人感兴趣的是文章最后的评论。
有人评论，说作者把领域模型的商业逻辑全部都写到Service层中，这样对于领域模型domain object而言，失去了OO的意义,回到了以前面向过程的设计中去了。
并拿出Martin fowler的Anemic Domain Model来举证。

这正是有意思。
于是正好让我拜读了Martin fowler的AnemicDomainModel这篇文章。

总结一下我的读后感：
domain object表示领域组件，如果把他们相关的业务逻辑都移到万能的上帝Service组件里，domain object的意义也就不是很重要了。
这对于OO而言也是不可取的。白痴domain object没有任何意义，业务功能让他们和service组件绑定到了一齐，要复用他们，就要复用他们所有的。
这造成Service 层和domain object层耦合太大，是有弊端的。
我们可以看到这样的情况下，Service中的重复代码很多，复用性不高。

Service组件从某种程度上来说是面向过程的。和use case中的用例有一定的对应关系。当然粒度会有不同。
所以对于OO来说，service这一层代表了不好的味道，要尽量的薄。它只不过是起到一种代理facade，调度组件的作用。
对于domain object来说，必须包含维护他们自身及相互关系的业务逻辑。如果将这部分逻辑放到service层去了，就是转移了相应的逻辑，造成Service中的重复代码增多，复用性降低。而domain就是对service的进一步改进使他更OO而不是一个流程这样他就有点过程性了!先理解到这里吧!后面再继续.....

话又说回来，基于面向过程的设计对于基于web的request-response机制来说到未必不好。
web的这种一来一往的交互性是具有过程性的。
用面向过程来进行描述，很多时候是方便，自然的。
这也许就是PHP, Python 、Perl等面向过程语言获得成功的原因。

自己的心得:
看完这个有了新得认识,觉得service是有点象面向用例的,这样他就侧重于业务的流程,如果我们将一个复杂的业务写在一个service类中可见会是什么样,代码很多.而domain则是为了