DDD 领域驱动设计思想
- 首先DDD是一种编程思想
编程思想的变化
-
pop–面向过程编程,是一种线性思维,相对简单,复杂的业务会导致代码冗余,实现复杂
-
oop–面想对象编程,封装继承多态,相对可以应对复杂情况,减少代码的冗余;
-
aop–面向切面编程,解决面对对象的静态问题,能突破类的限制,动态拓展类的功能;任意拓展功能,代码的复用;
oop的静态问题
-
对象生成分为2种:
- 编译时确定
- 运行时确定
-
对象即为一个整体,可以修改属性值等,但是其本身是稳定不变的;
-
其对象的功能可以通过一些设计模式进行一定程度上的增强;但其单位一样是类—原子;修改代码影响很大
-
从上就引入了aop,即不修改类,又能拓展功能;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iSTvTTPE-1598179902453)(/Users/varcan/Desktop/截屏2020-08-22 下午3.14.39.png)]
-
引入aop后,《验证用户登陆》,《异常处理》,《日志处理?》,《缓存处理》,都可以交给aop进行处理;代码整洁度提高,复用率提高,集中维护,方便维护升级;
-
aop是oop的拓展,解决了其拓展性的问题;
驱动设计 DDD
是一种系统分析设计的方法
- pop,无边界,全部的程序思想以线性化思维进行思考;一个大盒子–实现的所有步骤,所有细节放在一个盒子内;
- oop,有边界,程序思维以类为角度进行思考,无数个小盒子,即一个小盒子即一个类;
- ddd–解决问题:系统的规模日益变大;
- 解决问题和思考角度的规模大小举例:
- pop,建一个屋子;
- oop,建一个大厦;
- ddd,建一个城市;
ddd的具体思想
- 领域:从oop的基础上,划分一个更大的盒子,这个盒子不一定类似于oop的类的思想的盒子了。也不一定依赖于现实,这个盒子----领域;
- 这个盒子内,可以包含很多类;
- 2004年提出来了,因微服务的需要而重新火起来;
什么是DDD
Domain-driven-design
Domain–上文所述的大盒子
- 一个系统解决一个问题;
- 问题会包含多个模块(问题域);
- 拆分完作用域之后,会有一个统一的语言了;(工具)
- 需求
- 设计
- 开发
- 尤其针对不熟悉的业务
- 需求–设计—开发,增加业务语言的翻译次数;2层翻译;
Driven—驱动
-
基于领域,驱动领域设计;以领域为目标,为领域做设计;
-
基于领域驱动代码实现,拆分完具体的问题域以后,完成领域的需求;程序分析时(领域划分),不考虑实现;
Design–设计
- 领域是核心
- 数据库设计
- 程序设计
传统开发
1. 分析,数据加流程
2. 数据库设计
3. 界面加数据访问
4. 缺点--需求变更,其实是需求分析不够,《**开发和需求的语言不通**》;
5. **而领域则是先共同确定领域**
领域拆分
以电商系统为例子举例,类似于微服务系统的划分
一. 电商系统
- 商品中心
- 支付中心
- 订单中心
- 库存中心
- 用户中心
- 客服中心
- 评价系统
二. 细分子域
- 制定标准
- 业务规则
- 业务场景
- 业务流程
目标–沟通需求
约束领域
-
一张表,一个类,天然的划分,天然的边界
-
聚合根
-
领域设计的最小单位Entity,包含了数据层(EEModel)
DDD项目架构
千人千面;识业务而定,没有一定之规;拆分粒度的粗细
微服务架构于DDD的关系
DDD 的本质是一种软件设计方法,而微服务架构是具体的实现方式。
微服务同样需要服务拆分,拆分的粒度?—按照领域的方式
-
user Interface : 用户界面
-
application : 应用层,处理请求(不包含业务)
-
Domain:数据+业务
-
infrastucture:1.数据操作,2.数据存储,3.常用帮助类