JiveJdon Community Forums
在线90人 J道首页 | 论坛首页 | 培训咨询 | 开源框架 | 精华 | 查搜 | 注册 | 登陆 |
首页 » 论坛 » 设计模式、框架和架构
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表
???en_US.forumThreadNext.name??? 下一主题
这个主题共有 6 回复 ／ 1 页 [ ]  发表新帖子  回复该主题贴
hiswing

发表文章: 14
注册时间: 2004年12月27日 22:25
领域服务与应用服务的职责 发表: 2006年10月11日 10:22 回复
我们知道，在领域设计中，划分为三种模型，分别为：实体(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进行了划分？如果没有那么您是怎样考虑的呢？
banq

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

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

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

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

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

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

不知你是如何想？
hiswing

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

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

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

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

发表文章: 14
注册时间: 2004年12月27日 22:25
Re: 领域服务与应用服务的职责 发表: 2006年10月12日 09:38 回复
引用两段文字来说明问题：
“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里面。”

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

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

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

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 领域服务与应用服务的职责 发表: 2006年10月13日 09:52 回复
>Service层和Function层的关系应该是胃和小肠的关系一样
这是很形象比喻，现在确实没有这方面框架，Service层和Function层分离，从现在来看，好像更多还是分析领域的事情，必须由建模人员来指定哪些服务是应用还是领域。
这个主题有 6 回复 ／ 1 页 [ ]
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表    返回页首  返回页首
???en_US.forumThreadNext.name??? 下一主题
热点TAG: AOP cache DDD EJB 集群 设计模式 Hibernate IOC JiveJdon OO RBAC Spring Struts
查询本论坛内 回复超过的热门帖子
快速发表回复
标题
 
粗体 斜体 下划线 插入图片 插入代码 插入url链接 插入附件
内容
 

解惑之道在J道 ，打造中国最具影响力的的企业软件社区
OpenSource JIVEJDON v3.0 Powered by JdonFramework Code © 2002-07 jdon.com

anti spam