Domain-driven design 领域驱动设计
在查询有关资料时 看到的DDD与传统的MVC最大大区别便是 模型（Model）承载着业务的属性和具体的行为，是业务表达的方式、是DDD的内核。是一个类中有属性、属性有Get/Set方法，并且业务的行为（Action）操作也是在模型类中
为什么要使用DDD，在传统模型中，所有的业务放在了service层，再加上service层的相互调用，导致一个service十分庞大，可能会有几万行代码，并且错综复杂，在外部看来完全无法了解service的全部功能，导致后期的维护和扩展成本巨大。而通过DDD模型将业务拆分为一个个领域（领域可以有子领域），这样变可以知道每一个领域的具体内容。领域通过聚合根暴露自身，外部只能通过聚合根来调用领域
差别
传统的mvc模型
DDD模型
- 在MVC中业务全部在Service层实现，而DDD模型放到了Domin中
- DDD中API只是为了给外界暴露
- DDD中Domin 数据模型 不同于传统的POJO,它是充血的，包含了业务的行为。
DDD三层架构
API层
API层是作为对外打包、前端接口调用使用。Domian层是整个域模型，不能直接把它打包成maven给别人使用，也不能直接把它作为接口给前端使用，有些需要API层作为进行转换后调用Domain，对调用Domain返回的数据进行包装筛选后再返回出去。
Domain层
系统的核心层，所有具体的业务逻辑处理、事件处理等都在这层域模型中处理
Repository层
数据源代理层，Repository 层类似一个网关代理，它本身没有数据，数据都是通过它的代理来被Domain层访问，被代理的数据源可以是DB、ES还可以是HTTP、RPC任何与Domain层进行数据交互的都叫Repository。
Domain细节
Domain包含Entity,Server,ValueOject,MeteData,Factory、Repository包
其中的Model层分为Entity,Server,ValueOject这三种
- Entity (实体)
- 有特定的标识，标识着这个Model在系统中全局唯一
- 内部值可以是变化的，可能存在生命周期 (比如订单对象，状态值是连续变化的)
- 有状态的Value Object
- Value Object （值对象）
- 内部值是不变的，不存在生命周期 (比如地址对象不存在生命周期)
- 无状态对象
- Service （服务）
- 无状态对象
- 当一个属性或行为放在Entity、Value Object中模棱两可或不合适的时候就需要以Service的形式来呈现
其中复杂程度 由高到低分为 service -> entity -> Value Object
具体创建格式可以参照这篇文章
项目架构分层图
如上图，4层典型DDD分层结构，
1.展现层：controller层。无业务逻辑
2.应用服务层：此层可以包含查询逻辑，但核心业务逻辑必须下沉到领域层。
3.领域服务层：业务在这里组装。仓储（资源库）接口在此层定义。
4.基础设施层：仓储（资源库）实现层+PO持久化层。