在领域设计中，划分为三种模型，分别为：实体(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进行了划分？如果没有那么您是怎样考虑的呢？
bangq：
非常有道理，Evans DDD中的Service和我们传统的Service确实不一样，它主要划分为应用层服务和领域层服务以及基础结构层服务。
在我的JJ3案例中，我没有进行这种严格的分层分类，是以Web服务中的Service和操作Operations概念来区分的：
需要对外开放的、供客户端调用的我命名为服务，当然这个服务里也可能会区分为应用服务和领域服务；不对外开放，供业务层内部使用的普通operations就作为普通组件来看待。
个人目前感觉：应用服务和领域服务区分需要非常敏感，而且目前没有看到大大的好处。
有时，快速性 方便性确实必须注意，当然这个尺度是根据当事人的水平而定的。
无论如何，我们更应该来关注领域对象：也就是实体和值对象，当然，领域对象并不是无行为的对象，可以封装一些业务规则，不是简单的setter或getter行为。
不知你是如何想？
版主：
应用服务与领域服务的区分确实非常敏感且难以撑控，在较为复杂的应用中，应用服务与领域服务并不一定能够完全实现分离。这就需要不断地重构来完善，但并不一定能够完美(个人观点)。
我认同领域对象不应只是简单的setter或getter，可以封装一些业务规则。但前题是这些规则一定是它本身的职责才是，否则模型就会遭到破坏(面向对象的精要处)。
版主：
引用两段文字来说明问题：
“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里面。”
虽然领域对象是可以有行为能力的，但除领域对象之外一定是要业务对象的。业务对象应该操控多个领域对象的协作。并不是将所有的逻辑都塞到领域对象中。
bangq：
>但前题是这些规则一定是它本身的职责才是，否则模型就会遭到破坏(面向对象的精要处)。
所以，例如各种条件的查询，这些条件的筛选功能也应该属于规则，过去我们将数据筛选留给数据库SQL语句完成，现在DDD认为筛选应该在内存中完成，SQL文本也是一种规则。
>除领域对象之外一定是要业务对象的
引用Rod 的话容易引起误解，前面我们讨论过，我们的模型分领域对象和服务，领域对象又分实体和值对象。那么Rod这个业务对象又是什么呢？如果是服务，我们一般不会将服务称为对象，服务是一种组件模型，要么是服务，要么是操作operations
>Service层和Function层的关系应该是胃和小肠的关系一样
这是很形象比喻，现在确实没有这方面框架，Service层和Function层分离，从现在来看，好像更多还是分析领域的事情，必须由建模人员来指定哪些服务是应用还是领域。