对JiveJdon3中services设计的疑问

160649888
在JiveJdon3的源代码中,比如ForumMessageQueryServiceImp里面对MessageQueryDao产生了依赖,我觉得这样设计不合适,我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑,而和数据库(DAO)打交道的只有Repository,其他领域对象只依赖Repository,因为banq老师说过Repository就是对象仓库(我的理解就是相当于数据库),DDD书中有句话说:对象和存储之间的双向转换,是另一种领域设计构造---仓储的职责（p105 第二段最后一句话）。
还有个问题：
对于帖子
http://www.jdon.com/jivejdon/thread/31594.html
中说的banq老师说--对于批量查询"通过借道服务来实现"，通过服务，将Entity和它的大批量子对象使用专门批量查询组件实现,我觉得很合适.我的疑问是是否可以在应用层(DDD书 P49)直接调用Repository进行查询呢?如果不可以那我理解的依赖关系应该是这样：
application-->service-->Repository-->dao,service-->domin Object,
oojdon 2008-04-26 15:51
顶，这个问题问得好，我也想听听banq对DDD中仓储查询以及使用基于Specification(规格)的查询的理解。

不过我觉得把查询服务全部集中在ForumMessageQueryServiceImp系统显得更加清晰，如果你想查询仓储，增加一个间接层把ForumMessageQueryServiceImp中的方法移到仓储就是了。具体设计思想还是请banq出马！

-->我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑
好像在企业应用架构模式看到，服务的无状态操作特性，可以比喻为系统的简单API，它不应该承载业务逻辑。领域逻辑我们通常实现为组件形式，然后通过IOC容器装配。

banq 2008-04-28 10:09
>Service他里面应该只包含业务逻辑,
不是这样 ，Service如果包含逻辑，这就范了MF批评的贫血模型了，模型变得贫血了，因为业务逻辑不在模型中了。

application-->service-->Repository-->dao,service-->domin Object
这个不是很正确，如果说运行关系是这样的：application-->service-->Repository-->dao,service
但是domin Object不是最后，domin Object是贯穿这个流程中，这个流程为什么能够成立，都是因为domin Object，所以，如果application-->service-->Repository-->dao,service是一个办事流程，那么domin Object就是要办的事情。

比如，你要请假，你自己写请假单 部门批 人事部门批等，而请假单就是domin Object

yekongda 2008-04-28 12:22
160649888说“我觉得既然取名为service,那他只为领域对象服务,他里面应该只包含业务逻辑”，而oojdon说“服务的无状态操作特性，可以比喻为系统的简单API，它不应该承载业务逻辑。”，到底Service里承担业务逻辑吗（Service不就是封装业务逻辑吗）另外oojdon说的领域逻辑我理解是不是业务逻辑以外的都是领域逻辑，请指点
banq 2008-04-28 12:41
没有明白我上面举例吗？

每个部门都要审批处理请假单，比如人事部门，那么你难道就认为应该把请假业务逻辑包装在人事部门吗？

Service只是一个功能部门，如人事部门，当然不应该包含业务逻辑，业务逻辑在模型中，不能因为Service会激活相应的模型进行业务处理，就认为业务逻辑应该封装在Service中，这是两码事。

pengyan82311 2008-04-28 14:05
我可能也对于"Service"这个元素的理解还是本质上的错误。我原来理解是Domain Model或者Domain Model之间进行交互是通过调用Service（封装类业务逻辑）来实现的。我的这种想法中的DomainModel是不是根本还不能算是真正的对象。只能说是数据的载体。刚又看了下DDD中服务的章节。中说到“当一个操作进程不是实体或值对象本身的职责时，才把这个操作以Service的形式表现出来”而把业务逻辑放到服务中是根本就是不对的。

[该贴被pengyan82311于2008-04-28 14:08修改过]
yekongda 2008-04-28 14:17
我的理解是不是根本上就是大错特错，如果业务逻辑放到Service中后，DomainModel只剩下setter/getter也就是所谓的POJO了，通过看彭老师您的帖子，您好象反对POJO这个词，我的理解是不是这样的DomainModel不是有血有肉的对象，根本就不是真正领域对象呢。
banq 2008-04-28 14:49
>一个操作进程不是实体或值对象本身的职责时，才把这个操作以Service的形式表现出来
是的，这是原则，在JiveJdon3中你可能看到Domain Model是一个个set/get，但是在model的message子包中，我封装了大量论坛帖子的业务逻辑，它们以代理模式或装饰器模式出现，它们和你看到ForumMessage同属于完整的模型，只不过分开实现，这就是设计与分析的区别。
pengyan82311 2008-04-28 15:08
彭老师还要麻烦您下，我的部署好Jivejdon无法运行，麻烦您看下，完全是用网站的环境
http://www.jdon.com/jivejdon/thread/33959.html
160649888 2008-04-28 20:05
我重新看了下书.是我理解错了 在ddd中文版这本书P75页上有说:服务其实有两种服务,一是领域层服务;二是应用层服务.他们的不同点是:应用层上的服务没有任何业务含义,领域层的服务包括了基本的业务逻辑（引用pengyan82311 的话：一个操作进程不是实体或值对象本身的职责时，才把这个操作以Service（领域层的服务）的形式表现出来）;相同点:他们都是建立在大量的实体和值对象之上,有点像组织领域功能完成某种任务的脚本(P76),看书上的例子就能明白了.
应用层的服务是面向客户的,1:是连接客户和业务核心之间的桥梁,2:控制程序任务的进度状态,3:应用层服务依赖于领域层的所有对像,包括领域层的服务,实体对象,值对象,仓储,聚合,工厂.
不知理解的对不对,还请各位指教

[该贴被160649888于2008-04-28 20:22修改过]
banq 2008-05-04 15:32
应用层的服务实际只是和架构有关的功能，比如账单数据变化，需要提供一个消息机制通知相关人，这个就是属于应用层服务，应该是和领域模型无关的，160649888 说和所有领域层所有模型不敢苟同。

一般我们不会把应用层服务和领域模型行为混淆，因为两者区分很明显，领域模型应该是象鱼，而应用层服务象水，是与具体架构技术有关，领域模型脱离当前架构比如Java，还可以移植到其他水环境中，比如.NET等。

领域层服务容易和领域模型行为，很多人容易把领域模型行为也就是业务核心放入领域层服务中，我前面讨论的就是这种情况，虽然领域层服务控制了领域模型，但是不代表业务核心就要放入领域层服务，而应该放入领域模型中，这两者区别也有些鱼和水的区别，服务是SOA等架构，而领域模型则应该和架构无关，只和业务有关，脱离当前架构SOA也可以生存，比如移植到EDA架构也应该可以，如果你到EDA下，由于没有Service，而你的业务核心在Service，那你不是要重写软件了？

EDA
http://www.developer.com/design/article.php/3490671

EDA vs. SOA and Traditional Pub-Sub Systems
http://www.developer.com/design/article.php/10925_3499031_3

colingo 2008-05-05 14:57
>>>>>领域层服务容易和领域模型行为，很多人容易把领域模型行为也就是业务核心放入领域层服务中，我前面讨论的就是这种情况，虽然领域层服务控制了领域模型，但是不代表业务核心就要放入领域层服务，而应该放入领域模型中，这两者区别也有些鱼和水的区别，服务是SOA等架构，而领域模型则应该和架构无关，只和业务有关，脱离当前架构SOA也可以生存
说的好。
[该贴被xinying_ge于2008-05-05 14:59修改过]
xmuzyu 2008-06-14 02:14
按照DDD的思想，在EJB3.0架构中，我们可以把业务逻辑放在实体中，而这时候的实体，我们可以理解为domain object.而让我们的session bean和MDB只是协调实体来完成任务，只是作为实体的控制器，也就是让bean做为service,不知道这样理解对不对。还请banq老师和各位道友指点。
freebox 2008-06-14 08:42
实体是领域对象的一个组成部分。
如果一开始就从领域开始设计，就没有这么多问题了，我认为这些问题很大程度上是因为开始就想着怎么持久，怎么让view看得到。