Compare commits
85 Commits
bd1cf2a5a4
...
release
| Author | SHA1 | Date | |
|---|---|---|---|
| e6be173673 | |||
| 510309832f | |||
| d15bb5e10f | |||
| 06f315a654 | |||
| 245551961d | |||
| 636ae4d415 | |||
| 3a2f856eff | |||
| eb5d055e14 | |||
| 5771ffe388 | |||
| d59e59c17c | |||
| 4b2bba2ae9 | |||
| bebfcfa3f1 | |||
| 41489ba150 | |||
| 6c8032e25c | |||
| 9edce3e80c | |||
| 29570e7156 | |||
| 4be514aff0 | |||
| bad7025b00 | |||
| a3947239ad | |||
| f1ec30a7dd | |||
| 3699f4833c | |||
| 8ecdfbab6e | |||
| 57c4fcc6bc | |||
| a5e38099c6 | |||
| 854275fbda | |||
| 2794f1e10e | |||
| 50898d781e | |||
| 19efc38e5a | |||
| 9bc4cbf799 | |||
| 49a8165aff | |||
| ba9318c2ba | |||
| c50bb46f20 | |||
| 9042527142 | |||
| 1bf734f700 | |||
| 49ca7a2e72 | |||
| 44f7ffda1d | |||
| ec56219b83 | |||
| 4f3ca7936b | |||
| 44cc048899 | |||
| 3c00525d67 | |||
| e44351a362 | |||
| 51c2b14694 | |||
| 7eac1bbeb6 | |||
| 546e45aa97 | |||
| 7da8e3eb34 | |||
| 2384649928 | |||
| 2e2cb599cb | |||
| 00cf12ea3c | |||
| b870568483 | |||
| ce7c0ad997 | |||
| 7e07894422 | |||
| c3aaa9d2c0 | |||
| 73c82a4f97 | |||
| dcff8d4701 | |||
| 040a1999e3 | |||
| 636cb8a226 | |||
| b8255ca3a0 | |||
| e839e1e8a0 | |||
| 5d89a2907b | |||
| db667aefda | |||
| 25b04583e8 | |||
| 506b07d1ac | |||
| 555f1767a9 | |||
| f8d5a68fbc | |||
| 8dd43e784f | |||
| eb2bb0b62f | |||
| f945ec49bb | |||
| 6026fa7774 | |||
| b049e69454 | |||
| e9a6bc4d7e | |||
| b54b3149a2 | |||
| e448e3a9e1 | |||
|
|
f86f1b74e4 | ||
| 23706f21b2 | |||
| b4569dffb0 | |||
| f2764cefc9 | |||
|
|
e4225795f9 | ||
|
|
73803542ea | ||
|
|
a3afd54f97 | ||
|
|
8d028d116c | ||
|
|
47199b895c | ||
|
|
f253b4f628 | ||
|
|
1dcb2ce6a0 | ||
|
|
11eb3f3b37 | ||
|
|
9d0ccd1372 |
@@ -15,6 +15,15 @@ TOCO采用严格的分层架构:
|
||||
|
||||
技术栈:Java + SpringBoot + MyBatis-plus(读)+ Hibernate(写)
|
||||
|
||||
##平台能力边界说明:
|
||||
TOCO的设计模型旨在规范系统结构、统一数据契约与接口形态,自动生成约80%的基础代码框架(如控制器签名、DTO转换、读写方案执行器等)。
|
||||
然而,业务行为逻辑(如条件判断、动态路由、状态流转、异常处理、多源聚合、性能优化路径等)无法由设计自动推导或生成,必须由人工编码实现。
|
||||
因此:
|
||||
设计元素仅表达“系统能做什么”(接口定义、数据结构、依赖关系);
|
||||
**代码实现才是“系统正在做什么”**的唯一真实来源;
|
||||
设计与代码之间存在不可逾越的行为鸿沟——设计不记录实现细节,代码不反馈回设计;
|
||||
任何对系统行为的分析、影响评估或变更决策,都必须同时考察结构层面的设计信息与行为层面的代码实现,二者缺一不可。
|
||||
|
||||
## 重要设计元素详解
|
||||
|
||||
### 1. 模块(Module)
|
||||
@@ -124,6 +133,7 @@ TOCO采用严格的分层架构:
|
||||
- 手动创建自定义RPC
|
||||
- **参数限制**:只能为QTO、BTO、Enum、基本类型
|
||||
- **返回值限制**:只能为DTO、Enum、基本类型
|
||||
- **存储特点**: TOCO只存储RPC的方法签名,不存储执行逻辑。了解API内部具体实现需阅读对应代码
|
||||
|
||||
### 14. 应用程序接口(API)
|
||||
- **作用**:定义对外暴露的HTTP接口
|
||||
@@ -131,6 +141,7 @@ TOCO采用严格的分层架构:
|
||||
- **参数限制**:只能为QTO、BTO、EO、Enum、基本类型
|
||||
- **返回值限制**:只能为VO、Enum、基本类型
|
||||
- **分页处理**:框架自动包装返回值(code、message、data)
|
||||
- **存储特点**: TOCO只存储API的URI和方法签名,不存储执行逻辑。了解API内部具体实现需阅读对应代码
|
||||
|
||||
### 15. 流程服务(FunctionFlow)
|
||||
- **使用场景**:
|
||||
@@ -143,6 +154,12 @@ TOCO采用严格的分层架构:
|
||||
- 开始节点:流程起点
|
||||
- **设计原则**:以数据内聚为首要考虑,每个节点围绕核心写服务
|
||||
|
||||
16. 领域消息 (DomainMessage)
|
||||
可以监听聚合对象实体的创建、删除、更新事件;通过事件驱动的方式实现异步解耦;也是一种跨模块通信的方式;消息驱动的一种实现;
|
||||
|
||||
17. 普通消息 (CommonMessage)
|
||||
自定义字段,自持事务、延时特性;是对领域消息的补充
|
||||
|
||||
## 数据获取流程
|
||||
|
||||
### DTO获取流程
|
||||
|
||||
1960
knowledge.md
1960
knowledge.md
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user