DDD理论学习系列 -- 应用服务&领域服务（转）

转载：本文转载自： http://www.javashuo.com/article/p-bjfgneqp-nv.html

做者： 『圣杰』

出处： http://www.cnblogs.com/sheng-jie/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文连接，不然保留追究法律责任的权利。

1. 引言

单从字面理解，不论是领域服务仍是应用服务，都是服务。而什么是服务？从SOA到微服务，它们所描述的服务都是一个宽泛的概念，咱们能够理解为服务是行为的抽象。从前缀来看，根据DDD的经典分层架构，它们又隶属于不一样的层，应用服务属于应用层，领域服务属于领域层。

• 应用层（Application）：负责展示层与领域层之间的协调，协调业务对象来执行特定的应用程序任务。它不包含业务逻辑。
• 领域层（Domain）：负责表达业务概念，业务状态信息以及业务规则，是业务软件的核心。

因此综合来看应用服务是用来表述应用行为，而领域服务用来表述领域行为。
那怎么理解应用行为和领域行为呢，应用行为描述了一个具体操做从开始到结束的每个环节，而领域行为是对应用行为的细化，用来处理具体的某一个环节。好比，咱们手机购物，从购物车结算这一场景来举例，这就是一个应用行为。而这个应用行为又主要包括金额计算、支付、生成订单，这些子环节就能够理解为一个领域行为。

咱们就不咬文嚼字了，下面咱们就一一展开。

2. 应用服务

应用服务是用来表达用例和用户故事（User Story)的主要手段。

应用层经过应用服务接口来暴露系统的所有功能。在应用服务的实现中，它负责编排和转发，它将要实现的功能委托给一个或多个领域对象来实现，它自己只负责处理业务用例的执行顺序以及结果的拼装。经过这样一种方式，它隐藏了领域层的复杂性及其内部实现机制。

应用层相对来讲是较“薄”的一层，除了定义应用服务以外，在该层咱们能够进行安全认证，权限校验，持久化事务控制，或者向其余系统发生基于事件的消息通知，另外还能够用于建立邮件以发送给客户等。

应用层做为展示层与领域层的桥梁。展示层使用VO（视图模型）进行界面展现，与应用层经过DTO（数据传输对象）进行数据交互，从而达到展示层与DO（领域对象）解耦的目的。

3.领域服务

领域层就是较“胖”的一层，由于它实现了所有业务逻辑而且经过各类校验手段保证业务正确性。而什么是业务逻辑呢？业务流程、业务策略、业务规则、完整性约束等。

当领域中的某个操做过程或转换过程不是实体或值对象的职责时，咱们便应该将该操做放在一个单独的接口中，即领域服务。请确保该服务和通用语言时一致的；而且保证它是无状态的。

根据这句话咱们有几个问题须要理清：

1. 何时使用领域服务？
2. 领域服务无状态怎么理解？

领域服务是用来协调领域对象完成某个操做，用来处理业务逻辑的，它自己是一个行为，因此是无状态的。状态由领域对象（具备状态和行为）保存。

上面也说了，领域对象是具备状态和行为的。那就是说咱们也能够在实体或值对象来处理业务逻辑。那咱们该如何取舍呢？
通常来讲，在下面的几种状况下，咱们可使用领域服务：

• 执行一个显著的业务操做过程
• 对领域对象进行转换
• 以多个领域对象为输入，返回一个值对象。

4. 案例分析

咱们拿经典的转帐问题来分析一下：
而针对转帐这一操做，它的业务用例应该是这样的：

1. 检查帐号余额是否足够
2. 检查目标帐户帐号是否合法
3. 转帐
4. 短信通知转帐双方

其中1,2步是转帐的合法性校验属于转帐业务的一部分，因此，1,2,3均应该放到领域层经过领域服务来实现。短信通知，它并非是转帐的核心业务，由于这根据具体状况而定，好比只有客户订阅了帐号变更通知我才发短信。因此将第4步归类到应用服务中去实现，就确保了领域服务的纯粹性。

而至于持久化的问题，咱们能够这样想，领域逻辑应该只关心业务逻辑，才能保证领域逻辑的可重用性。将持久化放到应用层，咱们就会有更多的选择性。

5.总结

当应用服务中的逻辑趋于复杂时，咱们就要当心领域逻辑泄露到应用服务中去。而在使用领域服务时，咱们又要避免过分使用，由于会致使贫血领域模型。毕竟有些单一的操做更适合放到领域对象（实体和值对象）中去。

因此总结如下：

1. 服务是行为的抽象。
2. 应用服务经过委托领域对象和领域服务来表达用例和用户故事。
3. 领域对象（实体和值对象）负责单一操做。
4. 领域服务用于协调多个领域对象共同完成某个业务操做。
5. 应用服务不处理业务逻辑，领域服务处理业务逻辑。