ddd认为在application到infra层应该加一层domain
业务逻辑因该分为两大类，核心业务相似的，固定不变的应该放在domain这一层
application用来接入不同的应用场合会产生的不同业务逻辑
比如用户从网络端接入和从手机端接入，可能不同
比如用户登录网站和店家登录网站，逻辑也不同
application层存放不同场景对domain产生不同影响的业务逻辑
domain用于存放完全不会变动的逻辑
以前的infra存放第三方类库以及开源轮子，对其依赖
现在要求和infra尽可能解耦
应该是infra依赖已有的三层
已有的三层对其没有依赖关系
添加一层防腐层隔离
层与层之间数据传输的接口
prcscntation和application之间通过REST DTO传输或api，和用户接口的数据定义不能随意修改
application和infra传输的是entity，entity可能会发生变化，比如承载的状态，逻辑
所以有了两种不同的数据定义
entity的合法性也会在转化的时候封装在一起
domain层和数据库infra层之间的传输通过database DTO，也就是schema ，和rest DTO 一样不能被轻易修改。
domain做任何数据存取和读取的时候都需要介于entity和database dto之间做一个转换
dto定义在application层，划分出一个单独的dto包，方便其他包引用他，不会造成环形引用
domain层，repository，增删改查的仓库
repository会直接利用dao的interface来进行底层数据库访问
entity只会封装与自己本身相关个业务逻辑
entity：带有资源id以及有自己独立生命周期和状态表达的一种，比如订单，某一次银行转账
ValueObject：没有固定的id，没有生命周期，仅仅只有自己的一些属性，比如地址信息
entity和ValueObject是独立使用的
aggregates是一种超级权力的entity
访问entity通过aggregates来进行对其中entity数据操作
需要保证一个aggregates内部数据的一致性
标签：domain,DTO,邻域,逻辑,entity,application,驱动,infra,DDD From： https://www.cnblogs.com/15078480385zyc/p/17560591.html