733 lines
17 KiB
Markdown
733 lines
17 KiB
Markdown
# FMS 新系统核心架构设计 V2.0
|
||
|
||
> 文档版本：V2.0
|
||
> 编制日期：2026-09-30
|
||
> 文档状态：核心架构设计草案
|
||
> 适用范围：FMS/ERP 新系统第一阶段重构
|
||
|
||
## 1. 文档目的
|
||
|
||
本文档重新定义 FMS 新系统的核心架构，重点解决以下问题：
|
||
|
||
- SQL 是系统的第一等公民；
|
||
- 代码风格和模块实现方式统一；
|
||
- 第一阶段保持简单，不建设通用低代码平台；
|
||
- 真实业务表、业务 SQL 和业务代码拥有清晰边界；
|
||
- 支持一个租户多个公司，但不提前建设复杂的平台能力。
|
||
|
||
本文档替代旧设计中以 `s_module`、通用 CRUD 和动态 JSON 为中心的架构思路。旧表结构中的业务数据、工作流和可复用 SQL 可以迁移，但运行时中心需要重新组织。
|
||
|
||
## 2. 根本改变
|
||
|
||
### 2.1 旧架构
|
||
|
||
旧设计的主链路是：
|
||
|
||
```text
|
||
s_module
|
||
→ s_field
|
||
→ s_module_schema
|
||
→ 通用 SQL 拼接
|
||
→ 通用保存
|
||
→ 页面
|
||
```
|
||
|
||
它的优点是页面和简单模块创建较快，缺点是业务模块逐渐依赖元数据解释器，容易变成一个低代码平台。
|
||
|
||
### 2.2 新架构
|
||
|
||
新设计的主链路是：
|
||
|
||
```text
|
||
业务域代码包
|
||
→ 真实 SQL 表和视图
|
||
→ 业务查询与业务动作
|
||
→ API / 页面
|
||
```
|
||
|
||
新系统的中心不再是全局模块元数据，而是**业务域代码包**。每个业务域自己拥有表结构、迁移、SQL、业务动作和页面入口。
|
||
|
||
```text
|
||
客户域
|
||
├── 数据库迁移
|
||
├── 业务表和视图
|
||
├── 查询 SQL
|
||
├── 保存 SQL
|
||
├── 业务动作
|
||
├── 接口
|
||
├── 页面
|
||
└── 多语言资源
|
||
```
|
||
|
||
### 2.3 核心原则
|
||
|
||
```text
|
||
业务域是组织中心
|
||
SQL 表和视图是事实来源
|
||
SQL 文件是查询和处理的主要实现
|
||
业务代码负责动作和事务
|
||
页面是业务域的使用界面
|
||
配置只解决少量表现和参数问题
|
||
```
|
||
|
||
## 3. 总体架构
|
||
|
||
```text
|
||
租户注册配置
|
||
│
|
||
▼
|
||
租户数据库路由
|
||
│
|
||
▼
|
||
SQL Server 租户数据库
|
||
├── 系统内核
|
||
│ ├── 用户、角色和业务上下文
|
||
│ ├── 公司、组织、仓库和账簿
|
||
│ ├── 多语言和审计
|
||
│ └── 文件和运行记录
|
||
├── 业务域
|
||
│ ├── 客户和供应商
|
||
│ ├── 产品和基础资料
|
||
│ ├── 销售
|
||
│ ├── 采购
|
||
│ ├── 库存
|
||
│ └── 财务
|
||
├── 工作流
|
||
└── SQL 视图和报表
|
||
```
|
||
|
||
运行时链路：
|
||
|
||
```text
|
||
请求
|
||
→ 租户路由
|
||
→ 建立用户和公司上下文
|
||
→ 进入业务域
|
||
→ 执行查询或业务动作
|
||
→ SQL 事务
|
||
→ 审计记录
|
||
→ 返回结果
|
||
```
|
||
|
||
## 4. 核心内核
|
||
|
||
核心内核只提供所有业务域都需要的能力，不负责解释所有业务。
|
||
|
||
### 4.1 租户路由
|
||
|
||
第一阶段采用一个租户一个数据库：
|
||
|
||
- 租户注册信息使用配置文件；
|
||
- 一个租户对应一个 SQL Server 数据库；
|
||
- 租户库内不重复使用 `tenant_id` 过滤业务数据；
|
||
- 数据库连接由统一的 `TenantRegistry` 获取；
|
||
- 每个租户数据库单独执行迁移并记录版本。
|
||
|
||
平台库、在线租户开通和集中运维不进入第一阶段。
|
||
|
||
### 4.2 业务上下文
|
||
|
||
每次请求建立统一上下文：
|
||
|
||
```text
|
||
tenant_code
|
||
user_id
|
||
company_id
|
||
organization_id
|
||
warehouse_id
|
||
ledger_id
|
||
language
|
||
timezone
|
||
currency
|
||
request_id
|
||
```
|
||
|
||
上下文由运行时创建，业务域只能读取，不由页面自行拼接。SQL 和业务动作通过上下文得到当前公司、用户和账簿。
|
||
|
||
### 4.3 基础表
|
||
|
||
第一阶段的系统基础表：
|
||
|
||
```text
|
||
s_user
|
||
s_role
|
||
s_user_role
|
||
s_company
|
||
s_organization
|
||
s_warehouse
|
||
s_ledger
|
||
s_user_company
|
||
s_user_organization
|
||
s_user_warehouse
|
||
s_user_ledger
|
||
s_i18n_type
|
||
s_i18n
|
||
s_audit_log
|
||
s_file
|
||
```
|
||
|
||
角色先采用简单模型，不实现角色继承和复杂拒绝规则。公司、组织、仓库和账簿是明确的独立对象，不使用一个 `org_id` 代替它们。
|
||
|
||
## 5. 业务域代码包
|
||
|
||
### 5.1 业务域定义
|
||
|
||
业务域是新系统的主要代码组织单位，例如：
|
||
|
||
```text
|
||
customer
|
||
supplier
|
||
product
|
||
sales
|
||
purchase
|
||
inventory
|
||
finance
|
||
workflow
|
||
```
|
||
|
||
一个业务域负责自己的：
|
||
|
||
- 业务表和表关系；
|
||
- 数据库迁移；
|
||
- 查询视图；
|
||
- 查询 SQL；
|
||
- 保存 SQL；
|
||
- 业务动作；
|
||
- 事务边界；
|
||
- API；
|
||
- 页面；
|
||
- 多语言资源；
|
||
- 审计事件。
|
||
|
||
业务域之间通过明确的业务表关系、SQL 查询和服务接口协作，不通过全局 JSON 规则互相解释。
|
||
|
||
### 5.2 业务对象
|
||
|
||
业务对象仍然存在，但它属于业务域，而不是全局通用元数据引擎。
|
||
|
||
一个业务对象至少包含：
|
||
|
||
```text
|
||
对象编码
|
||
主表或视图
|
||
查询 SQL
|
||
保存方式
|
||
业务动作
|
||
```
|
||
|
||
例如销售订单：
|
||
|
||
```text
|
||
sales_order
|
||
├── b_sales_order
|
||
├── b_sales_order_line
|
||
├── sales_order_list.sql
|
||
├── sales_order_save.sql
|
||
├── submit_sales_order()
|
||
└── approve_sales_order()
|
||
```
|
||
|
||
### 5.3 业务域目录
|
||
|
||
建议使用以下代码组织方式：
|
||
|
||
```text
|
||
fms/
|
||
├── core/
|
||
│ ├── tenant/
|
||
│ ├── context/
|
||
│ ├── auth/
|
||
│ ├── audit/
|
||
│ └── i18n/
|
||
├── domains/
|
||
│ ├── customer/
|
||
│ │ ├── migration/
|
||
│ │ ├── sql/
|
||
│ │ ├── repository/
|
||
│ │ ├── service/
|
||
│ │ ├── api/
|
||
│ │ └── page/
|
||
│ ├── product/
|
||
│ ├── sales/
|
||
│ ├── purchase/
|
||
│ ├── inventory/
|
||
│ └── finance/
|
||
├── workflow/
|
||
└── shared/
|
||
```
|
||
|
||
每个业务域使用同一种目录结构，不允许某个模块把 SQL 放数据库字段、另一个模块把 SQL 放页面代码、第三个模块再放配置 JSON。
|
||
|
||
## 6. SQL 设计
|
||
|
||
### 6.1 SQL 的职责
|
||
|
||
SQL 负责：
|
||
|
||
- 查询；
|
||
- 关联；
|
||
- 分组和统计；
|
||
- 排序和分页；
|
||
- 批量更新；
|
||
- 事务内的数据处理；
|
||
- 报表和视图。
|
||
|
||
业务代码负责：
|
||
|
||
- 业务动作入口；
|
||
- 事务编排；
|
||
- 状态变化；
|
||
- 幂等处理；
|
||
- 跨模块规则；
|
||
- 库存和财务业务约束。
|
||
|
||
### 6.2 SQL 文件规范
|
||
|
||
SQL 统一放在业务域目录下：
|
||
|
||
```text
|
||
domains/sales/sql/
|
||
├── order_list.sql
|
||
├── order_detail.sql
|
||
├── order_save.sql
|
||
├── order_submit.sql
|
||
└── order_report.sql
|
||
```
|
||
|
||
SQL 命名统一使用：
|
||
|
||
```text
|
||
对象_动作.sql
|
||
```
|
||
|
||
例如：
|
||
|
||
```text
|
||
customer_list.sql
|
||
customer_save.sql
|
||
customer_disable.sql
|
||
sales_order_submit.sql
|
||
inventory_lock.sql
|
||
```
|
||
|
||
### 6.3 通用 CRUD 的边界
|
||
|
||
新架构不移除通用 CRUD，但不把通用 CRUD 作为所有业务的默认核心。它可以用于简单基础资料，核心业务必须由业务域自己的 SQL 和业务动作实现。
|
||
|
||
以下内容不再作为系统核心：
|
||
|
||
- 数据库中的 `b_query_sql` 作为所有模块的默认查询入口；
|
||
- `b_save_table` 驱动所有业务模块的通用保存；
|
||
- `b_order_sql` 在运行时任意拼接排序；
|
||
- 全局 `data / virtual` 模块解释器；
|
||
- 页面 JSON 中的业务公式和业务写入规则；
|
||
- 一张通用配置表承载所有业务行为。
|
||
|
||
内部开发人员可以自由编写 SQL，但 SQL 由对应业务域维护，并与代码和迁移一起发布。
|
||
|
||
### 6.4 通用保存边界
|
||
|
||
通用保存仅用于简单基础资料。以下内容必须使用业务域专用服务和 SQL：
|
||
|
||
- 库存扣减、锁定和释放；
|
||
- 采购和销售状态推进；
|
||
- 财务过账和反过账；
|
||
- 公司间交易；
|
||
- 审批提交和审批动作；
|
||
- 任何需要多个业务表一致提交的操作。
|
||
|
||
## 7. 数据库模型
|
||
|
||
### 7.1 表分层
|
||
|
||
```text
|
||
s_* 系统内核和控制数据
|
||
b_* 业务主表和业务明细表
|
||
wf_* 工作流定义和运行数据
|
||
```
|
||
|
||
核心业务表使用真实列和真实关系，不使用全量 EAV。
|
||
|
||
### 7.2 公司字段
|
||
|
||
公司级业务表根据业务实际需要包含：
|
||
|
||
```text
|
||
company_id
|
||
organization_id
|
||
warehouse_id
|
||
ledger_id
|
||
```
|
||
|
||
跨公司业务另外保存：
|
||
|
||
```text
|
||
source_company_id
|
||
target_company_id
|
||
settlement_company_id
|
||
```
|
||
|
||
共享基础资料不复制多份，使用共享范围或公司关联表表达。
|
||
|
||
### 7.3 动态字段
|
||
|
||
第一阶段不支持普通用户通过页面配置直接创建数据库字段。新增业务字段使用：
|
||
|
||
```text
|
||
迁移脚本增加物理列或扩展表
|
||
→ 更新查询 SQL 和视图
|
||
→ 更新页面字段定义
|
||
→ 增加多语言资源
|
||
```
|
||
|
||
字段分为：
|
||
|
||
1. 核心字段：真实列，参与业务逻辑和统计；
|
||
2. 扩展字段：通过迁移增加的可选列或扩展表字段；
|
||
3. 低频扩展：JSON，仅用于非核心展示。
|
||
|
||
需要筛选、排序、统计或导出的字段不能只放在 JSON 中。
|
||
|
||
运行时字段分为两种情况：
|
||
|
||
- **表现字段**：标签、显隐、只读、排序和布局可以运行时调整；
|
||
- **物理字段**：需要存储、查询、排序、统计或导出的字段，必须通过 SQL Migration 增加物理列或扩展表。
|
||
|
||
后续如果确实需要管理员在线增加物理字段，可以增加一个受控的字段变更服务，由它生成并执行 SQL Migration，同时更新视图、字段定义和页面配置。这个过程仍然是数据库结构变更，不是普通 JSON 配置。
|
||
|
||
### 7.4 数据库约束
|
||
|
||
数据库负责结构完整性：
|
||
|
||
- 主键；
|
||
- 外键；
|
||
- 唯一索引；
|
||
- 非空约束；
|
||
- 必要 CHECK；
|
||
- 查询和关联索引。
|
||
|
||
不使用触发器替代库存、财务和审批业务流程。业务规则放在业务域服务和事务 SQL 中。
|
||
|
||
## 8. 页面和配置
|
||
|
||
### 8.1 页面不是元数据生成的
|
||
|
||
核心业务页面由业务域代码实现。页面可以复用通用列表、表单和查询组件，但页面的字段、动作和业务行为由业务域明确声明。
|
||
|
||
页面配置只保存：
|
||
|
||
- 列显示顺序；
|
||
- 列宽；
|
||
- 表单分组；
|
||
- 查询默认值；
|
||
- 用户个人偏好；
|
||
- 显示格式。
|
||
|
||
不使用 JSON 描述完整业务页面和业务处理器。
|
||
|
||
### 8.2 模块表的定位
|
||
|
||
如果保留 `s_module`，它只用于：
|
||
|
||
- 菜单和路由登记；
|
||
- 权限对象登记；
|
||
- 模块名称和多语言资源键；
|
||
- 业务域对象的索引。
|
||
|
||
它不负责：
|
||
|
||
- 生成所有 SQL；
|
||
- 推断所有保存逻辑；
|
||
- 承载业务状态；
|
||
- 解释任意 JSON 规则。
|
||
|
||
### 8.3 公司差异
|
||
|
||
第一阶段不建设通用的租户、公司、部门、角色多层配置继承。
|
||
|
||
确实存在公司差异时，在具体业务表中直接使用 `company_id`，例如：
|
||
|
||
```text
|
||
s_number_rule(company_id, domain_code, field_code)
|
||
wf_binding(company_id, domain_code, event_code)
|
||
s_print_template(company_id, template_code)
|
||
```
|
||
|
||
不把所有差异都抽象为一个通用覆盖引擎。
|
||
|
||
## 9. 权限
|
||
|
||
权限采用简单的角色模型：
|
||
|
||
```text
|
||
s_role
|
||
s_user_role
|
||
s_role_permission
|
||
s_role_data_scope
|
||
s_user_company
|
||
```
|
||
|
||
权限对象绑定业务域和业务动作：
|
||
|
||
```text
|
||
customer.read
|
||
customer.create
|
||
sales_order.submit
|
||
sales_order.approve
|
||
inventory.adjust
|
||
finance.post
|
||
```
|
||
|
||
第一阶段支持：
|
||
|
||
- 用户可用公司；
|
||
- 用户可用组织；
|
||
- 用户可用仓库；
|
||
- 模块访问权限；
|
||
- 业务动作权限；
|
||
- 简单数据范围。
|
||
|
||
不实现角色继承、拒绝权限和通用权限表达式。复杂范围由对应业务域的 SQL 实现。
|
||
|
||
## 10. 工作流
|
||
|
||
工作流是业务域的流程编排器，不是业务规则中心。
|
||
|
||
工作流绑定业务域动作：
|
||
|
||
```text
|
||
sales_order.submit
|
||
sales_order.approve
|
||
purchase_order.submit
|
||
expense.approve
|
||
```
|
||
|
||
工作流可以决定：
|
||
|
||
- 下一节点；
|
||
- 审批人；
|
||
- 当前流程状态；
|
||
- 需要调用哪个业务动作。
|
||
|
||
业务域负责真正的动作：
|
||
|
||
- 销售订单批准后是否允许出库；
|
||
- 采购收货如何增加库存；
|
||
- 财务单据如何过账；
|
||
- 审批失败如何补偿。
|
||
|
||
工作流实例固定流程版本，历史审批记录只追加不修改。
|
||
|
||
## 11. 多语言
|
||
|
||
第一阶段保持简单：
|
||
|
||
```text
|
||
s_i18n_type
|
||
s_i18n
|
||
```
|
||
|
||
系统文案使用稳定资源键：
|
||
|
||
```text
|
||
sales.order.name
|
||
sales.order.customer
|
||
action.submit
|
||
```
|
||
|
||
业务主数据使用业务域自己的翻译表：
|
||
|
||
```text
|
||
b_product
|
||
b_product_translation
|
||
b_customer
|
||
b_customer_translation
|
||
```
|
||
|
||
系统资源可以放在代码资源文件或租户库中，但必须统一一种来源。第一阶段不实现三层 overlay、翻译变更集和运行时语言管理。
|
||
|
||
历史单据保存产品名称、客户名称、税率、地址、币种和金额等快照。
|
||
|
||
## 12. 配置和版本
|
||
|
||
第一阶段不建设覆盖所有对象的通用配置版本引擎。
|
||
|
||
配置分为三类：
|
||
|
||
| 类型 | 实现方式 |
|
||
| --- | --- |
|
||
| 数据库结构 | SQL Migration |
|
||
| 业务逻辑 | 代码和业务 SQL |
|
||
| 页面表现 | 页面代码和少量布局配置 |
|
||
| 工作流 | 独立流程版本表 |
|
||
| 业务参数 | 明确的参数表 |
|
||
|
||
只有工作流、编号规则、打印模板等确实需要历史追溯的内容，才单独设计版本。
|
||
|
||
### 12.1 SQL Migration
|
||
|
||
SQL Migration 是按顺序执行、可追踪的数据库结构变更脚本。例如：
|
||
|
||
```text
|
||
migration/
|
||
├── V001__create_company.sql
|
||
├── V002__create_customer.sql
|
||
└── V003__add_customer_tax_no.sql
|
||
```
|
||
|
||
迁移工具在每个租户数据库中记录已执行的版本。发布新代码时，先执行缺少的迁移，再启动依赖新结构的代码。
|
||
|
||
Migration 可以包含：
|
||
|
||
- 建表、改表和删表；
|
||
- 增加或停用字段；
|
||
- 创建视图、索引和约束；
|
||
- 初始化字典和系统数据；
|
||
- 必要的数据回填。
|
||
|
||
Migration 不等于运行时页面配置。页面配置可以立即保存，数据库结构变化则必须经过迁移记录。
|
||
|
||
数据库迁移记录：
|
||
|
||
```text
|
||
schema_version
|
||
migration_name
|
||
checksum
|
||
executed_at
|
||
```
|
||
|
||
## 13. 代码风格和目录规范
|
||
|
||
新系统的代码按业务域组织，不按页面组织，也不按一组通用配置表组织。
|
||
|
||
```text
|
||
domains/
|
||
sales/
|
||
migration/
|
||
sql/
|
||
repository/
|
||
service/
|
||
api/
|
||
page/
|
||
i18n/
|
||
```
|
||
|
||
统一要求：
|
||
|
||
- 一个业务动作只有一个主要入口；
|
||
- SQL 统一放业务域的 `sql` 目录；
|
||
- 页面只调用业务域 API，不直接写业务 SQL；
|
||
- 业务域不通过另一个域的内部表直接修改数据；
|
||
- 数据库表、SQL、服务、接口和页面使用同一业务名称；
|
||
- 新增抽象必须来自至少两个真实业务域的重复需求。
|
||
|
||
数据库命名在新系统中一次确定：
|
||
|
||
- 表名使用小写 `snake_case`；
|
||
- 系统表使用 `s_`；
|
||
- 业务表使用 `b_` 或明确业务域前缀；
|
||
- 工作流表使用 `wf_`；
|
||
- 字段命名统一使用一套规则，不再混用 `b_`、`mx_` 和裸字段名。
|
||
|
||
## 14. 第一阶段建设范围
|
||
|
||
第一阶段只建设架构内核和一条完整业务链路。
|
||
|
||
### 14.1 必须完成
|
||
|
||
1. SQL Server 迁移工具和数据库版本表；
|
||
2. 租户数据库连接和路由；
|
||
3. 用户、角色、公司、组织、仓库和账簿；
|
||
4. 统一业务上下文；
|
||
5. 业务域目录和 SQL 调用约定；
|
||
6. 基础权限和公司范围；
|
||
7. 审计日志；
|
||
8. 基础多语言；
|
||
9. 一个业务域的表、SQL、服务、接口和页面完整闭环。
|
||
|
||
### 14.2 建议示例
|
||
|
||
建议先做客户或产品域：
|
||
|
||
```text
|
||
SQL Migration
|
||
→ 真实业务表
|
||
→ 查询 SQL
|
||
→ 保存 SQL
|
||
→ 业务域服务
|
||
→ API
|
||
→ 页面
|
||
→ 公司权限
|
||
→ 审计
|
||
```
|
||
|
||
这个示例必须验证“业务域代码包是中心”，不只是验证通用页面是否能显示。
|
||
|
||
### 14.3 第一阶段不做
|
||
|
||
- 以全局 `s_module` 驱动的通用 CRUD 作为核心业务默认实现；
|
||
- 全局 `s_field` 驱动的运行时字段创建；
|
||
- 通用页面设计器；
|
||
- 通用公式和规则解释器；
|
||
- 全对象配置版本和变更集；
|
||
- 多层公司配置覆盖；
|
||
- 复杂多语言发布体系；
|
||
- 集团分析库和跨租户业务查询。
|
||
|
||
## 15. 第一阶段验收标准
|
||
|
||
### 15.1 架构中心
|
||
|
||
- 一个业务域拥有自己的迁移、SQL、服务和页面；
|
||
- 业务域可以不依赖通用模块解释器运行；
|
||
- 页面配置不能替代业务代码；
|
||
- 工作流只能调用明确登记的业务动作。
|
||
|
||
### 15.2 SQL 驱动
|
||
|
||
- 业务查询可以直接在 SQL Server 中验证；
|
||
- 复杂查询使用业务域 SQL 文件或视图；
|
||
- 业务表和关联关系是真实 SQL 结构；
|
||
- 新增可统计字段需要物理列或索引扩展；
|
||
- 不为了页面功能复制业务表。
|
||
|
||
### 15.3 简单和一致
|
||
|
||
- 同类业务域使用相同目录和调用流程；
|
||
- 不存在同一类配置的多种格式；
|
||
- 不存在同一业务动作的多个通用入口；
|
||
- 数据库迁移和代码可以一起发布；
|
||
- 第一阶段不依赖通用低代码运行时。
|
||
|
||
## 16. 旧设计迁移原则
|
||
|
||
旧设计不是全部废弃，而是按职责迁移：
|
||
|
||
| 旧内容 | 新系统处理方式 |
|
||
| --- | --- |
|
||
| 真实业务表 | 保留并按业务域归属整理 |
|
||
| 业务 SQL | 移入对应业务域 `sql` 目录 |
|
||
| `wf_*` 工作流表 | 保留，改为绑定业务动作 |
|
||
| `s_module` | 降为菜单、权限和对象索引 |
|
||
| `s_field` | 降为字段说明，不负责运行时造字段 |
|
||
| `s_module_schema` | 页面局部配置，不作为核心运行时 |
|
||
| 通用保存接口 | 仅保留简单基础资料使用 |
|
||
| JSON 公式和动态规则 | 迁移到业务代码或 SQL |
|
||
| `b_query_sql` 等全局 SQL 字段 | 逐步迁移到业务域 SQL 文件 |
|
||
|
||
## 17. 最终架构关系
|
||
|
||
```text
|
||
业务域代码包是组织中心
|
||
SQL 表和视图是事实来源
|
||
SQL 文件是查询和处理的主要实现
|
||
业务代码负责动作和事务
|
||
页面负责交互
|
||
工作流负责流程编排
|
||
少量配置负责表现和参数
|
||
```
|
||
|
||
新系统不是旧系统增加一层配置，也不是把旧模块表重新命名。它的核心变化是：
|
||
|
||
> **从元数据驱动的通用模块，改成业务域驱动的 SQL 应用。**
|