服务
领域服务层简介
有时，对象不是一个事物。 在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上讲不属于任何对象。与其把它们强制地归于哪一类，不如顺其自然地在模型中引入一种新的元素，这就是SERVICE（服务）。
有些重要的领域操作无法放到ENTITY或VALUE OBJECT中。这当中有些操作从本质上讲是一些活动或动作，而不是事物，但由于我们的建模范式是对象，因此要想办法将它们划归到对象这个范畴里。
一些领域概念不适合被建模为对象。如果勉强把这些重要的领域功能归为ENTITY或VALUE OBJECT的职责，那么不是歪曲了基于模型的对象的定义，就是人为地增加了一些无意义的对象。
所谓SERVICE，它强调的是与其他对象的关系。与ENTITY和VALUE OBJECT不同，它只是定义了能够为客户做什么。SERVICE往往是以一个活动来命名，而不是以一个ENTITY来命名，也就是说，它是动词而不是名词。SERVICE也可以有抽象而有意义的定义，只是它使用了一种与对象不同的定义风格。SERVICE也应该有定义的职责，而且这种职责以及履行它的接口也应该作为领域模型的一部分来加以定义
好的SERVICE有以下3个特征。 (1) 与领域概念相关的操作不是ENTITY或VALUE OBJECT的一个自然组成部分。 (2) 接口是根据领域模型的其他元素定义的。 (3) 操作是无状态的。
当领域中的某个重要的过程或转换操作不是ENTITY或VALUE OBJECT的自然职责时，应该在模型中添加一个作为独立接口的操作，并将其声明为SERVICE。定义接口时要使用模型语言，并确保操作名称是UBIQUITOUS ANGUAGE中的术语。此外，应该使SERVICE成为无状态的。
应用服务层与领域服务层
应用层SERVICE和领域层SERVICE可能很难区分。应用层负责通知的设臵，而领域层负责确定是否满足临界值，
这里还是很容易混淆的，原本一个服务层就够了，为何会出现两个服务层，其作用又是什么？
首先我们要了解应用服务层是做什么的？
其作用是完成用户所发出的指令，比我要去买一本书，用户只需要告诉你，我要买这书，发出这样的订单！
如果不涉及到领域层时，我们可能需要将计算价格，优惠的策略，库存的增减.....等一系列操作，都放在应用层。
领域服务层的作用
对于上面的分析，我们不难看出其代码的耦合多先不说，用户的操作与实际业务高度的耦合在一起，这在起初也许还好，但是随着时间的推移，各种问题就会暴露出来。
上面的问题我们已经看出来，那么就来说说领域服务层的作用
当用户发出一个订单的时候，其本质就是发出了一个指令，她并不关心其中的真正业务处理，就像我们坐电梯一样，我们只需要按楼层就可以，具体是上还是下，我们也不关心。
不难看出，其应用服务层不应该包含真是的业务处理逻辑，只需要关系自己发出的指令已经得到的响应，而其锁的具体业务逻辑应该在领域层中完成
至此我们再来总结应用服务与领域服务的区别：
应用服务处理软件系统的应用场景或者叫用例；领域服务处理业务的核心逻辑，与是否有软件系统没有关系。
应用服务中处理更多的是系统横切面的非功能需求，如事务、安全等。
Last updated