DDD-总结

什么叫DDD？

从名称入手，顾名思义DDD（domain driven design）,领域驱动设计，是一种设计思想。

个人浅薄的理解，DDD主要是想告诉我们在程序设计中，从领域出发，由领域驱动设计，不是由项目驱动设计，也不是由过程驱动设计，先由领域专家进行领域建模，围绕领域进行功能分解，再由开发进行领域实现。

践行DDD可以从6w模型入手,首先介绍一下什么是6W模型

6W模型:  why（业务价值）、who（利益相关知者/角色）、when（业务过程）、what（业务功能）、where（业务范围）、how（业务实现）

 

 

 

为什么要使用DDD?

为什么要使用DDD呢，首先我们从面向对象设计入手，我们项目中用到的对象都是贫血模型，对象只有属性没有行为，对象只是作为承载数据的容器，我们涉及的业务规则都堆积在了service层

其次，我们再从数据库的操作来入手，代码中显示的使用SQL语句获取结果集，直接将SQL语句暴露出来

 

DDD和我们以往的设计有什么不同？

项目结构不同

• 传统的项目结构：界面层 + 业务逻辑层 + 数据库层
• DDD的项目结构：用户接口层 + 应用层 + 领域层 + 基础实施层

领域层对标业务逻辑层，数据库层对标基础设施层，增加了一个应用层

充血模型&&贫血模型

• 传统项目的对象是贫血模型（只有属性）
• DDD对应的对象是充血模型（具有属性+行为）

数据库操作

• 传统的项目将SQL暴露在项目代码中
• DDD将SQL统一交由Repository（仓储）处理

业务逻辑处理

• 传统项目将业务逻辑放在servicwe
• DDD将业务逻辑放在领域层

对象的创建以及生命周期的管理

• 传统项目对象的创建和生命周期的管理是由sprin来管理的
• DDD对象的创建和生命周期的管理是由Repository来管理的（通过factory【工厂】来创建对象，通过Repository【仓储】来管理周期的中间和结束）

       每一个聚合对应一个仓储

使用DDD有什么好处？

1. 将业务聚焦于模型
2. 封装对数据库的操作，模型的变动不会影响原有的业务
3. 边界上下文的划分，引入抽象，隔离了外界变化对内部的影响，引入封装隔离了内部变化对外界的影响

DDD的一些专有名词

• 实体
• 值对象
• 聚合
• 领域服务
• 领域事件
• 边界上下文
• 仓储
• 工厂

使用DDD有什么弊端？

如何去实现DDD？