DDD邻域驱动设计的基础理解

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内部数据的一致性