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

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

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

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

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

 

 

引用两段文字来说明问题：
“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里面。”

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

 

ddd中有这样的一段话：
要区分应用层服务和领域层服务是非常困难的，
细粒度的领域对象会导致信息从领域层转到应用层，需要应用层来处理复杂的领域对象交互作用，从而是领域信息从领域层上消失，而出现在应用代码和用户接口代码中，明智的引入领域服务可以有效的帮助我们分清领域层和应用层的界限。
书中也举了一个例子：
例如转账服务
应用层 资金转账应用服务
1.读取输入(例如xml请求)
2.发送消息给领域服务，要求处理
3.监听确认消息
4.决定用基础结构层的服务发送通告
领域层 资金转账领域服务
1.必要的帐户和分类账对象的相互作用，完成正确的提取和存入
2.去人转账结果（转账是否被允许或拒绝等）