Skip to content

Commit f020b4c

Browse files
Alice52Alice52
committed
fix(dist): refine dist note
1 parent 3c4703f commit f020b4c

14 files changed

Lines changed: 536 additions & 303 deletions

‎database‎

ddd/01.introduce.md renamed to ddd/01.ddd.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,3 +27,8 @@
2727
- 限界上下文:
2828
- 领域建模: ，领域层包含了多个聚合，共同实现核心业务逻辑
2929
- **领域事件**: 这种事件发生后通常会导致进一步的业务操作
30+
3. 思考维度
31+
32+
- 新增的模型没有给你带来收益。比如有没有帮助系统解耦，有没有提升业务语义表达能力的提升，有没有提升系统的可维护性和可测性等等
33+
- 统一语言、边界上下文、防腐层(应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦)
34+
- 领域建模，就是对问题域进行抽象，找到核心概念（实体），然后再构建实体之间的关系的过程: 组合，使用，继承、泛化

‎ddd/02.cola.md‎

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
- client: 独立(只需要依赖组件)
2+
- domain: 独立
3+
- infrastructure: 实现 domain(可以使用 client)
4+
- app: 实现 client | 依赖 infrastructure->domain
5+
- adapter: 使用 app -> app
6+
7+
![269594562-c8cfcb86-df64-4d33-b26d-2065b2ac411e](https://github.com/fork-repoes/COLA/assets/42330329/b0e6770a-6372-4468-b74c-8d204f6953a5)
8+
9+
![269593571-4fadbbea-80c9-44e8-9344-879b0e9475e7](https://github.com/fork-repoes/COLA/assets/42330329/13468e44-2ed0-4fbd-b1b2-5d19cefd01de)
10+
11+
## COLA 架构: 框架(提升应用质量)
12+
13+
| 层次 | 包名 | 功能 | extra | 必选 |
14+
| :----------------- | :---------- | :---------------------------------- | :--------------------- | :--- |
15+
| Adapter 层(VO/DTO) | openapi | 封装 http, rpc 接口 | | 否 |
16+
| | controller | 处理 http 请求 | 浏览器 | 否 |
17+
| | scheduler | 处理定时任务 | 定时任务 | 否 |
18+
| | consumer | 处理外部 message | 消息 | 否 |
19+
| App 层(DTO) | executor | 处理 request, 包括 command 和 query | | 是 |
20+
| | service | 与 domain 交互负责编排任务 | | 是 |
21+
| Domain 层(Entity) | gateway | 领域网关, 解耦利器 | 粗略的理解成一种 SPI | 是 |
22+
| | model | 领域模型 | | 否 |
23+
| | ability | 领域能力, DomainManager | 领域对外暴露的服务能力 | 否 |
24+
| Infra 层(DO) | gatewayimpl | 网关实现 | | 是 |
25+
| | mapper | ibatis 数据库映射 | | 否 |
26+
| | config | 配置信息 | | 否 |
27+
| Driven adapter | db | 数据库 | | 否 |
28+
| | search | 搜索引擎 | | 否 |
29+
| | rpc | 外部接口 | | 否 |
30+
| Client SDK | api | 服务对外透出的 API | | 是 |
31+
| | dto | 服务对外的 DTO | | 是 |
32+
33+
## COLA 组件: 框架功能(可复用组件 + 提升研发效率)
34+
35+
| 组件名称 | 功能 | 依赖 |
36+
| :------------------------------- | :-------------------------------------------------- | :------------------ |
37+
| cola-component-catchlog-starter | 异常处理和日志组件 | exception、dto 组件 |
38+
| cola-component-domain-starter | Spring 托管的领域实体组件 | 无 |
39+
| cola-component-dto | 定义了 DTO 格式, 包括分页 | 无 |
40+
| cola-component-exception | 定义了异常格式, 主要有 BizException 和 SysException |
41+
| cola-component-extension-starter | 扩展点组件 | 无 |
42+
| cola-component-statemachine | 状态机组件 | 无 |
43+
| cola-component-test-container | 测试容器组件 | 无 |
44+
45+
## 相关细节
46+
47+
1. 包的划分: 综合考虑功能和领域两个维度包结构定义
48+
![image](https://github.com/fork-repoes/COLA/assets/42330329/807e547c-117d-4d72-a287-f9b3f6643161)
49+
50+
![image](https://github.com/fork-repoes/COLA/assets/42330329/3b5df4a4-f5e4-4813-a558-85771d4f7fe2)
51+
52+
2. 防腐层: Anti-Corruption
53+
54+
- ddd 的概念: 应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦
55+
- 在 COLA 中将数据库等都泛化为外部依赖, 利用依赖倒置(变成了不直接依赖数据库等-依赖数据库的抽象), 统一使用 gateway 来实现业务领域和外部依赖的解耦: Domain 层定义 Gateway + Infrastructure 提供实现
56+
57+
![image](https://github.com/fork-repoes/COLA/assets/42330329/94e68d92-d39a-40ba-ae50-0ae41ed323c5)
58+
![image](https://github.com/fork-repoes/COLA/assets/42330329/516ea1f6-1443-4510-947c-491143acd81a)
59+
60+
- pros: 降低了对外域信息依赖的耦合
61+
- pros: 是通过上下文映射, 确保本领域边界上下文下领域知识的完整性，实现了统一语言
62+
63+
## client - app - adaptor
64+
65+
1. client 定义接口(类似与 openapi 定义|类似于 app 实现的接口)
66+
```java
67+
interface CustomerServiceI {
68+
listByName();
69+
}
70+
```
71+
2. app 实现接口
72+
```java
73+
@Service
74+
public class CustomerServiceImpl implements CustomerServiceI {
75+
@Resource private CustomerListByNameQryExe customerListByNameQryExe;
76+
@Override
77+
public MultiResponse<CustomerDTO> listByName(CustomerListByNameQry customerListByNameQry) {
78+
return customerListByNameQryExe.execute(customerListByNameQry);
79+
}
80+
}
81+
```
82+
3. adaptor 调用 client 接口提供 controller/openapi 等服务
83+
```java
84+
@RestController
85+
public class CustomerController {
86+
@Autowired private CustomerServiceI customerService;
87+
@GetMapping(value = "/customer")
88+
public MultiResponse<CustomerDTO> listCustomerByName(@RequestParam(required = false) String name){
89+
CustomerListByNameQry customerListByNameQry = new CustomerListByNameQry();
90+
customerListByNameQry.setName(name);
91+
return customerService.listByName(customerListByNameQry);
92+
}
93+
}
94+
```

‎ddd/03.mvcm.md‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
> **Note** > `Manager 层提供原子的服务接口，Service 层负责依据业务逻辑来编排原子接口`
2+
> 实际开发中 Manager 层得使用建议
3+
>
4+
> 1. 复杂业务，service 提供数据给 Manager 层，负责业务编排
5+
> 把事务下沉到 Manager 层，`Manager层不允许相互调用`，不会出现事务嵌套
6+
> 2. 专注于不带业务 sql 语言，也可以在 manager 层进行通用业务的 dao 层封装
7+
> 3. 避免复杂的 join 查询，在 manager 层拆分成简单 SQL
8+
> 4. 对 Service 层通用能力的下沉, 如缓存方案、中间件通用处理
9+
> 5. 对第三方平台封装的层
10+
11+
![image](https://github.com/fork-repoes/COLA/assets/42330329/ec1d5605-6db7-4915-ae11-c28761f360d4)
12+
13+
1. 开放接口层: 进行 网关安全控制、流量控制等
14+
- 可直接封装 Service 方法暴露成 RPC 接口
15+
- 通过 Web 封装成 http 接口
16+
2. 终端显示层：前端 js,html,css 渲染
17+
3. Web 层
18+
- 主要是对访问控制进行转发
19+
- 各类基本参数校验
20+
- 异常处理等
21+
4. Service 层：相对具体的业务逻辑服务层 | 与 DAO 交互
22+
5. Manager 层：通用业务处理层
23+
- 对第三方平台封装的层，预处理返回结果及转化异常信息，适配上层接口
24+
- 对 Service 层通用能力的下沉, 如缓存方案、中间件通用处理；
25+
- 对多个 DAO 的组合复用
26+
6. DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。
27+
28+
![image](https://github.com/fork-repoes/COLA/assets/42330329/d5276111-8f2c-4823-be1e-1d65927e2c30)
29+
30+
## manager 层使用举例
31+
32+
1. 提供原子的服务接口(供 serverice 进行编排调用): `/GetUser 方法在不同终端具有不同得行为`
33+
34+
- 在 APP 中展示用户信息的时候，如果用户不存在，那么要自动给用户创建一个用户
35+
- 同时，要做一个 HTML5 的页面，HTML5 页面要保留之前的逻辑，也就是不需要创建用户
36+
![image](https://github.com/fork-repoes/COLA/assets/42330329/351ee065-017e-4d23-8fbb-05618fd5c20d)
37+
38+
- `添加Manager层以后，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责将这两个接口组装起来`
39+
40+
2. 减小长事务且避免嵌套事务
41+
42+
```java
43+
// service: 典型没必要得长事务
44+
@Transactional(rollbackFor = Throwable.class)
45+
public Result<String> upOrDown(Long departmentId, Long swapId) {
46+
// query 1
47+
// query 2
48+
// do update
49+
departmentDao.updateById(swapEntity);
50+
return Result.OK("success");
51+
}
52+
```
53+
54+
```java
55+
// service: 只进行
56+
@Transactional(rollbackFor = Throwable.class)
57+
public Result<String> upOrDown(Long departmentId, Long swapId) {
58+
// query 1
59+
// query 2
60+
61+
xxxManager.upOrDown(departmentSort,swapEntity);
62+
return Result.OK("success");
63+
}
64+
65+
// xxxManager
66+
@Transactional(rollbackFor = Throwable.class)
67+
public void upOrDown(DepartmentEntity departmentEntity ,DepartmentEntity swapEntity){
68+
// do update
69+
departmentDao.updateById(swapEntity);
70+
}
71+
```

‎ddd/README.md‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,43 @@
1+
## 应用架构 BFF
2+
3+
![image](https://github.com/fork-repoes/COLA/assets/42330329/11e3299d-a670-4266-b6f4-6eefd800401f)
4+
5+
1. 架构的本质: 是要素 & 结构
6+
7+
- 要素: 指架构中的主要元素
8+
- 结构: 结构是指要素之间的相互关系
9+
10+
2. 组织架构
11+
12+
- 要素: 人(定义人的职责划分)
13+
- 结构: 人与人之间的关系(人与人之间协作关系)
14+
15+
3. 应用架构: 难点(怎么落地-最佳实践)
16+
17+
- 要素: 代码(class | conponent | package | module)
18+
- 结构: 代码组织(管理组织代码)
19+
- 原则:
20+
1. ${\color{red}提倡以业务为核心(多核心/不同domain)}$
21+
2. ${\color{red}分离业务复杂度和技术复杂度 }$
22+
3. ${\color{red}抽象共性,合理分层(module)/分包: 职责单一 + 解耦_外部_依赖 + 提供最佳实践}$
23+
- _核心目标_ :
24+
1. 从繁杂的业务系统中提炼出共性, 找到解决业务问题的最佳共同模式
25+
2. 定义良好的应用结构，提供最佳实践
26+
3. 应用系统处理复杂业务逻辑也应该是分层的，下层对上层屏蔽处理细节，每一层各司其职，分离关注点
27+
28+
4. 应用架构
29+
30+
- 分层架构:mvcm
31+
- **COLA**
32+
- DDD 架构: 六边形架构/洋葱圈架构
33+
- 整洁架构（Clean Architecture）
34+
35+
5. 系统典型(共有)业务
36+
37+
- 接收 request，响应 response；
38+
- 做业务逻辑处理，像校验参数，状态流转，业务计算等等；
39+
- 和外部系统有联动，像数据库，微服务，搜索引擎等；
40+
141
### DDD
242

343
1. 中台 & 微服务 & DDD
@@ -25,3 +65,10 @@
2565

2666
4. 领域事件
2767
5. 微服务分层设计
68+
69+
---
70+
71+
## reference
72+
73+
1. https://blog.csdn.net/significantfrank/article/details/110934799
74+
2. https://blog.csdn.net/significantfrank/article/details/132241986

0 commit comments

Comments
 (0)