jdon 解惑授道,企业信息化解决之道
 

热点Tag: AOP cache DDD EJB 集群 设计模式 Hibernate IOC JiveJdon OO RBAC Spring Struts

Jdon框架演示

JiveJdon3.0
源码下载

GoF设计模式

在线教程

社区精彩讨论












领域服务与应用服务的职责

作者:hiswing 发表时间:2006年10月11日 10:22 回复此消息回复

原贴网址: http://www.jdon.com/jivejdon/thread/29132.html

我们知道,在领域设计中,划分为三种模型,分别为:实体(Entity)、值对象(Value Object)、和服务(Service)。其中Service与我们传统设计中的Service有什么不同呢?

让我们来回忆一下,通常我们针对将读写xml、资金转账等代码放在service中,可以看出,该层包括了两种含义,一种是与业务无关的,一种是与业务紧密关联的。领域驱动设计将这两层含义进一步划分,《Domain-Driven Design》中的例子那样:如果银行应用可以将我们的交易转化并输出电子表格文件,那么这种输出就应该是应用服务。而负责处理资金转帐的借贷关系,应该属于领域层,它包括了基本的业务逻辑,而技术层上的服务则根本没有任何业务含义。由此得知,将传统设计中的Service继续划分,得到应用服务与领域服务。领域层和应用层的服务是相互合作,由应用Service指挥领域对象来解决问题。

如此划分,可以使各层的结构和职责更加清晰,技术与业务进一步分离。

以上是我个人的理解,有不对之处还请指正。

另仔细阅读实战DDD(Domain-Driven Design领域驱动设计),在该文中说到:“在JiveJdon3中,com.jdon.jivejdon.service.ForumService和Forum实体模型及其值对象ForumState共同完成领域模型,其中ForumService属于应用服务层;而后两者属于领域层;其他服务ForumMessageService、AccountService和UploadService等都是此类性质。”在JiveJdon3中并没有对领域与应用Service进行明确的划分,而是由ForumService来完成。JJ3的代码我没有看过,只是从这段文字还这样判断的,有不对之处还请包含。请问,JJ3中是否对Service进行了划分?如果没有那么您是怎样考虑的呢?

Re: 领域服务与应用服务的职责 发表: 2006年10月11日 11:59 回复
banq 发表文章: 8914/ 注册时间: 2002年08月03日 17:08
非常有道理,Evans DDD中的Service和我们传统的Service确实不一样,它主要划分为应用层服务和领域层服务以及基础结构层服务。

在我的JJ3案例中,我没有进行这种严格的分层分类,是以Web服务中的Service和操作Operations概念来区分的:

需要对外开放的、供客户端调用的我命名为服务,当然这个服务里也可能会区分为应用服务和领域服务;不对外开放,供业务层内部使用的普通operations就作为普通组件来看待。

个人目前感觉:应用服务和领域服务区分需要非常敏感,而且目前没有看到大大的好处。

有时,快速性 方便性确实必须注意,当然这个尺度是根据当事人的水平而定的。

无论如何,我们更应该来关注领域对象:也就是实体和值对象,当然,领域对象并不是无行为的对象,可以封装一些业务规则,不是简单的setter或getter行为。

不知你是如何想?


Re: 领域服务与应用服务的职责 发表: 2006年10月11日 13:04 回复
hiswing 发表文章: 14/ 注册时间: 2004年12月27日 22:25
应用服务与领域服务的区分确实非常敏感且难以撑控,在较为复杂的应用中,应用服务与领域服务并不一定能够完全实现分离。这就需要不断地重构来完善,但并不一定能够完美(个人观点)。

我认同领域对象不应只是简单的setter或getter,可以封装一些业务规则。但前题是这些规则一定是它本身的职责才是,否则模型就会遭到破坏(面向对象的精要处)。

Re: 领域服务与应用服务的职责 发表: 2006年10月12日 00:04 回复
junglesong 发表文章: 36/ 注册时间: 2006年06月07日 14:05
应用服务层应该根据业务形成自己的框架,留待接口提供给领域服务层使用。
也许服务层应该还是Service类,领域服务层应该归结在Function层中,也就是多了新的一层。只是现在还缺乏针对这方面的框架。

Service层和Function层的关系应该是胃和小肠的关系一样,不知两位是否同意我的看法。

Re: 领域服务与应用服务的职责 发表: 2006年10月12日 09:38 回复
hiswing 发表文章: 14/ 注册时间: 2004年12月27日 22:25
引用两段文字来说明问题:
“OO编程的技术是一门代理的艺术。职责划分明确,把接口定义好,把实现交给另外的类来做。首先把变化的部分和不变的部分 划分出来。不变的部分,就成了框架。变化的部分,就是程序员自己做。 ”

领域对象是可以有行为能力的,在Rod Johnson的《without EJB》第10章《持久化》中有一段文字:“领域对象包含的逻辑,这里称之为“domain logic”,这些domain logic应该最小化的依赖于DAO,而我们讨论的那些需要持久化操作参与的事务性逻辑,这里称之为“workflow methods”,这些“workflow methods”应该放在“business facade”,而不应该放在domain object里面。可重用度很高的操作可能是domain logic,应该放在domain object里面;比较难重用的控制逻辑方法,特别是可跨越多个domain object的操作则放在business facade object里面。”

虽然领域对象是可以有行为能力的,但除领域对象之外一定是要业务对象的。业务对象应该操控多个领域对象的协作。并不是将所有的逻辑都塞到领域对象中。

Re: 领域服务与应用服务的职责 发表: 2006年10月13日 09:45 回复
banq 发表文章: 8914/ 注册时间: 2002年08月03日 17:08
>但前题是这些规则一定是它本身的职责才是,否则模型就会遭到破坏(面向对象的精要处)。
所以,例如各种条件的查询,这些条件的筛选功能也应该属于规则,过去我们将数据筛选留给数据库SQL语句完成,现在DDD认为筛选应该在内存中完成,SQL文本也是一种规则。

>除领域对象之外一定是要业务对象的
引用Rod 的话容易引起误解,前面我们讨论过,我们的模型分领域对象和服务,领域对象又分实体和值对象。那么Rod这个业务对象又是什么呢?如果是服务,我们一般不会将服务称为对象,服务是一种组件模型,要么是服务,要么是操作operations

Re: 领域服务与应用服务的职责 发表: 2006年10月13日 09:52 回复
banq 发表文章: 8914/ 注册时间: 2002年08月03日 17:08
>Service层和Function层的关系应该是胃和小肠的关系一样
这是很形象比喻,现在确实没有这方面框架,Service层和Function层分离,从现在来看,好像更多还是分析领域的事情,必须由建模人员来指定哪些服务是应用还是领域。

这个主题共有 6 回复 / 1 页 [ ]
 
上一篇: 什么是真正的OO阿 下一篇: 向高手请教hibernate
 
查询本论坛 最热门帖子
快速发表回复:
标题
 
粗体 斜体 下划线 插入图片 插入代码 插入url链接 插入附件
内容
 
联系我们 | 关于我们 | RSS订阅 | 广告联系 | 网站地图 | 设为首页
Copyright (C) 2002-2007 Jdon.com, All Rights Reserved 版权所有 上海解道计算机技术有限公司
沪ICP备05018152号 如有意见请与我们联系 Powered by JdonFramework