DDD领域驱动设计

DDD 领域驱动设计思想

1. 首先DDD是一种编程思想

编程思想的变化

1. pop–面向过程编程，是一种线性思维，相对简单，复杂的业务会导致代码冗余，实现复杂

2. oop–面想对象编程，封装继承多态，相对可以应对复杂情况，减少代码的冗余；

3. aop–面向切面编程，解决面对对象的静态问题，能突破类的限制，动态拓展类的功能；任意拓展功能，代码的复用；

oop的静态问题

1. 对象生成分为2种：

   1. 编译时确定
   2. 运行时确定

2. 对象即为一个整体，可以修改属性值等，但是其本身是稳定不变的；

3. 其对象的功能可以通过一些设计模式进行一定程度上的增强；但其单位一样是类—原子；修改代码影响很大

4. 从上就引入了aop，即不修改类，又能拓展功能；

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iSTvTTPE-1598179902453)(/Users/varcan/Desktop/截屏2020-08-22 下午3.14.39.png)]

5. 引入aop后，《验证用户登陆》，《异常处理》，《日志处理？》，《缓存处理》，都可以交给aop进行处理；代码整洁度提高，复用率提高，集中维护，方便维护升级；

6. aop是oop的拓展，解决了其拓展性的问题；

驱动设计 DDD

是一种系统分析设计的方法

1. pop，无边界，全部的程序思想以线性化思维进行思考；一个大盒子–实现的所有步骤，所有细节放在一个盒子内；
2. oop，有边界，程序思维以类为角度进行思考，无数个小盒子，即一个小盒子即一个类；
3. ddd–解决问题：系统的规模日益变大；
4. 解决问题和思考角度的规模大小举例：
   1. pop，建一个屋子；
   2. oop，建一个大厦；
   3. ddd，建一个城市；

ddd的具体思想

1. 领域：从oop的基础上，划分一个更大的盒子，这个盒子不一定类似于oop的类的思想的盒子了。也不一定依赖于现实，这个盒子----领域；
2. 这个盒子内，可以包含很多类；
3. 2004年提出来了，因微服务的需要而重新火起来；

什么是DDD

Domain-driven-design

Domain–上文所述的大盒子

1. 一个系统解决一个问题；
2. 问题会包含多个模块（问题域）；
3. 拆分完作用域之后，会有一个统一的语言了；（工具）
   1. 需求
   2. 设计
   3. 开发
   4. 尤其针对不熟悉的业务
   5. 需求–设计—开发，增加业务语言的翻译次数；2层翻译；

Driven—驱动

1. 基于领域，驱动领域设计；以领域为目标，为领域做设计；

2. 基于领域驱动代码实现，拆分完具体的问题域以后，完成领域的需求；程序分析时（领域划分），不考虑实现；

Design–设计

1. 领域是核心
   1. 数据库设计
   2. 程序设计

传统开发

1. 分析，数据加流程
2. 数据库设计
3. 界面加数据访问
4. 缺点--需求变更，其实是需求分析不够，《**开发和需求的语言不通**》；
5. **而领域则是先共同确定领域**

领域拆分

以电商系统为例子举例，类似于微服务系统的划分

一. 电商系统

1. 商品中心
2. 支付中心
3. 订单中心
4. 库存中心
5. 用户中心
6. 客服中心
7. 评价系统

二. 细分子域

1. 制定标准
2. 业务规则
3. 业务场景
4. 业务流程

目标–沟通需求

约束领域

1. 一张表，一个类，天然的划分，天然的边界

2. 聚合根
   

3. 领域设计的最小单位Entity，包含了数据层（EEModel）

DDD项目架构

千人千面；识业务而定，没有一定之规；拆分粒度的粗细

微服务架构于DDD的关系

DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。

微服务同样需要服务拆分，拆分的粒度？—按照领域的方式

1. user Interface ： 用户界面

2. application ： 应用层，处理请求(不包含业务)

3. Domain：数据+业务

4. infrastucture：1.数据操作，2.数据存储，3.常用帮助类