2023-11-06 16:05:27 +08:00
|
|
|
|
---
|
|
|
|
|
|
title: 领域驱动设计
|
|
|
|
|
|
categories:
|
2023-12-26 10:59:02 +08:00
|
|
|
|
- CS
|
2023-11-06 16:05:27 +08:00
|
|
|
|
status: doing
|
2023-12-26 12:54:52 +08:00
|
|
|
|
abbrlink: 31204
|
2023-11-06 16:05:27 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 参考文献
|
|
|
|
|
|
|
|
|
|
|
|
- [蚂蚁金服数据体验技术团队 - 领域驱动设计](https://juejin.cn/post/6844903618680881165)
|
|
|
|
|
|
- [美团 - 领域驱动设计在互联网业务开发中的实践](https://tech.meituan.com/2017/12/22/ddd-in-practice.html)
|
|
|
|
|
|
- [领域驱动实战思考](https://huhao.dev/posts/61190ae2/#%E9%97%AE%E9%A2%98%E5%AD%90%E5%9F%9F%E8%AF%86%E5%88%AB)
|
|
|
|
|
|
- [基于 DDD 的前端项目架构设计与实战](https://www.tangshuang.net/8663.html)
|
|
|
|
|
|
- [React 语境下前端 DDD 的思考](https://www.tangshuang.net/8212.html)
|
|
|
|
|
|
|
|
|
|
|
|
# 架构对比
|
|
|
|
|
|
|
|
|
|
|
|
从后端视角看，对比传统的三层架构，领域驱动
|
|
|
|
|
|
|
|
|
|
|
|
- `充血`复用了：领域对外的接口
|
|
|
|
|
|
- `领域服务`封装了：领域之间的联系
|
|
|
|
|
|
|
|
|
|
|
|
贫血模型->充血模型，降低了`service层`的负担，同时保证了业务迭代，`entity`的独立性
|
|
|
|
|
|
|
|
|
|
|
|
## MVC
|
|
|
|
|
|
|
|
|
|
|
|
从数据库视角、分析实体出发，进行系统的构建
|
|
|
|
|
|
|
|
|
|
|
|
- DAO 层
|
|
|
|
|
|
- Service 层
|
|
|
|
|
|
- Controller 层
|
|
|
|
|
|
|
|
|
|
|
|
## 后端 DDD
|
|
|
|
|
|
|
|
|
|
|
|
> 针对基础设施层，也可以考虑加入`防腐层`、`工厂`
|
|
|
|
|
|
|
|
|
|
|
|
一个领域基本四层架构
|
|
|
|
|
|
|
|
|
|
|
|
1. 用户层(user interface): 对标 controller，对外提供 web 服务、接口
|
|
|
|
|
|
2. 应用层(application): 业务层，定义领域可以解决的问题 `domainService`
|
|
|
|
|
|
3. 领域层(domain): 纯粹的描述业务实体
|
|
|
|
|
|
4. 基础设施层(infra): 持久化层(Builder+repository)
|
|
|
|
|
|
|
|
|
|
|
|
同时，领域拆分带来如下两个致命问题
|
|
|
|
|
|
|
|
|
|
|
|
- 领域化(微服务)后，数据库是分开的，导致实体调用链复杂，避免跨库查询
|
|
|
|
|
|
- 避免分布式事务同步
|
|
|
|
|
|
|
|
|
|
|
|
## 前端 DDD
|
|
|
|
|
|
|
|
|
|
|
|
> ?? 这里存在一个问题，api 网关到底要不要挪到前端领域目录下来开发
|
|
|
|
|
|
|
|
|
|
|
|
1. 用户层: web、mobile、mini-program ...多端
|
|
|
|
|
|
2. service: 暴露给 UI 组件的 `domainSerivce`，组织实体的状态流转
|
|
|
|
|
|
3. entity: 实体、聚合实体、事件
|
|
|
|
|
|
4. infra: api 请求、缓存、工具
|
|
|
|
|
|
|
|
|
|
|
|
## 工厂 Factory / Builder
|
|
|
|
|
|
|
|
|
|
|
|
- 数据库表设计层面，如果要`多对多`的关系，只能很别扭的设计一个中间表。
|
|
|
|
|
|
- 实体 A 适合 `mongo`文档形存储，实体 B 适合`mysql`关系型存储。对于 `Builder` 而言，直接在这个领域搓出来 `A 和 B` 的 `CRUD`的实现方法
|
|
|
|
|
|
|
|
|
|
|
|
## 防腐层 Facade / Adaptor
|
|
|
|
|
|
|
|
|
|
|
|
也被成为适配器，隔离第三方/外部服务，例如场景，用户上传文件到阿里云、腾讯云
|
|
|
|
|
|
|
|
|
|
|
|
```js
|
|
|
|
|
|
class UserUploadServiceFacade extends UserService {
|
|
|
|
|
|
/**
|
|
|
|
|
|
* 上传
|
|
|
|
|
|
*/
|
|
|
|
|
|
async upload(oss) {
|
|
|
|
|
|
if (oss === "ali") return "OK";
|
|
|
|
|
|
if (oss === "tx") return "FAIL";
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
# 领域模型
|
|
|
|
|
|
|
|
|
|
|
|
实体的`贫血->充血`是一个随着业务发展过程演变的结果，初期业务场景不明确，很难充血，瞎几把充血，纯属找难受。
|
|
|
|
|
|
|
|
|
|
|
|
是否需要引入`聚合根(aggregate root)`的概念，解决领域内实体独立、平铺关系带来的不方便，这个可能比较看心情
|
|
|
|
|
|
|
|
|
|
|
|
## 贫血模型(POJO)的问题
|
|
|
|
|
|
|
|
|
|
|
|
> 脱离了业务复杂度谈分层，好比抛开剂量谈毒性
|
|
|
|
|
|
|
|
|
|
|
|
领域对象里只有`get/set`方法，所有的业务逻辑都不包含在内，从而造成`失忆症`，从实体中，无法知道发生了那些业务，需要去 `service层` 里挨个梳理，一旦业务迭代、`service 层`直接开始变成屎山
|
|
|
|
|
|
|
|
|
|
|
|
## 充血模型 && 领域服务的关系
|
|
|
|
|
|
|
|
|
|
|
|
> 确保领域之间独立的，随着不断的充血，保证领域(实体)是独立发展的
|
|
|
|
|
|
|
|
|
|
|
|
假定两个 domain(实体)：
|
|
|
|
|
|
|
|
|
|
|
|
- 学生: 上课、做作业
|
|
|
|
|
|
- 老师、全体起立、布置作业
|
|
|
|
|
|
|
|
|
|
|
|
假定`老师`调用`全体起立`，对应肯定要`学生`调用`上课`，这个就是 `领域服务(domainService)` 需要去处理的，他俩不能建立直接的联系。
|
|
|
|
|
|
|
|
|
|
|
|
- 增加新的业务逻辑：在 `domainService` 增加新的方法。
|
|
|
|
|
|
- 调整旧的业务逻辑：修改`学生`，`老师`，内部具体的方法，`domainService` 完全不需要变化。
|
