DDD领域驱动设计

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持久化层。

参考文档 领域驱动设计(DDD)-基础思想 领域驱动设计
DDD领域驱动设计落地实践（十分钟看完，半小时落地）