精读DDD：service

 精读DDD，今天再次理解一下service，概念以及应用到实际工作中出现的一些错误。

之前的一些博客：

ABP学习笔记：领域服务 和 应用服务 区别_董厂长的博客-CSDN博客_领域服务和应用服务区别

ABP：是否应该在一个应用服务中调用另外一个应用服务？_董厂长的博客-CSDN博客_一个服务调用另一个服务

服务的生命周期，以及使用场景的思考_董厂长的博客-CSDN博客_abp的 应用服务和领域服务生命周期 

Service设计的初衷：

特殊的操作不属于任何对象。与其强制性地归于一类，不如在模型中加入新的一种元素，服务。

（通常以Manager结尾）

作用：避免去扰乱真正的模型对象

简单理解：Entity 和 Value Object 是名词，内部不应该包含各种操作。Service是动词，对实体或者值对象的操作应该放到服务里面去。

那么在实际项目中，确实出现了在实体中加入一些操作的现象，但是目的也很明确，仅仅是对实体的属性进行一些更改，清空，赋初始值等操作。例如：dog class 中，dog.claer() 来清除某个实体的所用属性。

划重点：Service的参数和结果应该是领域对象。他没有状态。

特征：

1.  用于实体和值对象向外界进行交互

2.  接口是根据领域模型的其他元素定义的

3. 操作是无状态的（状态由上层控制）栗子：fun（x）=> { if(x=1){...} } 这就是有状态的

如何区分应用层Service和领域层Service？

应用层负责通知你做什么？领域层负责如何去做。

这边有个理解误区，实际项目中发现很多事情在ApplicationService中也做了，那么这边的重点是“领域知识的划分”

举个例子：导出患者信息的功能如何做？

首先，导出到excel，对于项目来说，“文件格式” 是一个没有领域知识的术语，所以导出这一步应该被放在应用服务中。但是，患者信息 与实体相关 属于 领域知识，那么就应该被放在领域服务中。

个人理解：应用层的Service相当于调度者，调用多个Domian层的服务。 为什么这么做呢，因为两个领域服务之间是不互知的。

举个例子： 

基础设施层就当一个library就行了