精读DDD，今天再次理解一下service，概念以及应用到实际工作中出现的一些错误。
之前的一些博客：
ABP学习笔记：领域服务 和 应用服务 区别_董厂长的博客-CSDN博客_领域服务和应用服务区别
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就行了
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
