20260919211702

code/fms/FMS模块设计评审.md

@@ -1,13 +1,15 @@
 # FMS 模块设计评审
 
 > 版本：v1.2。评审对象：`FMS新系统核心表结构设计.md`（模块 / 字段 / 界面配置 / 模块关系 / 权限）。
-> 关联：`FMS删除规则引擎设计.md`（已按本评审定案修订为 v2.0）、`开发规范.md`、`CODEBUDDY.md`。
+> 关联：`FMS删除策略重构设计.md`（当前删除策略架构）、`开发规范.md`、`CODEBUDDY.md`。
 > 一句话：**骨架是对的，改三处即可——关系删除行为一列化、配置分节按业务问题分、规则表达对齐权限体系。**
 >
-> v1.1 修订：问题一原建议「加 `b_relation_kind` 语义列 + 按语义推导默认行为」，定案为**不加语义列、单列 `b_on_delete` 四值**——语义列与删除行为同轴，不提供额外信息；被引用方由基数判定。`FMS删除规则引擎设计.md` 已同步修订为 v2.0。
+> v1.1 修订：问题一原建议「加 `b_relation_kind` 语义列 + 按语义推导默认行为」，定案为不加语义列、单列 `b_on_delete` 表达删除行为。该部分已由当前删除策略重构重新收敛为三值方案。
 >
 > v1.2 修订：第八节第 3、4 项定案——中间表模块统一挂业务域节点下（规范已写入 `FMS新系统核心表结构设计.md` §4.3）；模块管理分节调整随删除规则前端改造同一批实施。
 
+> 当前实施以 `FMS删除策略重构设计.md` 为准。本评审中关于四值删除行为、归档、勾条件、引用规则和 `s_rule` 的章节保留为历史讨论，不再作为实施规格。
+
 ---
 
 ## 一、总评
@@ -58,7 +60,7 @@
 3. **唯一只有配置者知道的事**是四选一的行为本身（被引用方是否独占拥有引用方），单列直接表达它；
 4. 与 `开发规范.md`「为真实出现的第二个使用方而抽象」一致——不为「表单将来可能用语义做别的」预留列。
 
-最终结构（详规见 `FMS删除规则引擎设计.md` v2.0 §3）：
+最终结构（历史方案；当前方案详见 `FMS删除策略重构设计.md`）：
 
 ```sql
 alter table dbo.s_relation add
@@ -154,7 +156,7 @@ alter table dbo.s_relation add
 - 去掉 `b_hook`（一期只有 `delete.pre` 一种取值，属过早抽象）；
 - 去掉 `b_scope_type`（同上）。
 
-已按此修订 `FMS删除规则引擎设计.md`（v2.0）。
+该历史方案已由 `FMS删除策略重构设计.md` 取代。
 
 ---
 
@@ -189,21 +191,21 @@ alter table dbo.s_relation add
 
 | 设计/文档有 | 实际状态 |
 | --- | --- |
-| 删除规则引擎（`FMS删除规则引擎设计.md` §6.4/§6.5 整节） | **后端零实现**：`s_rule` / `deleteobj` / `b_on_delete` / `b_archived` 在 `fms-api` 中全部 grep 无匹配 |
+| 删除策略引擎（`FMS删除策略重构设计.md`） | **后端零实现**：删除计划、SQL 规则检查、`deleteobj` 和 `b_on_delete` 执行链路仍待实现 |
 | `DataSaveService` 的 delete 分支接入规则检查 | 未实现，`DataSaveService.java:470` 直接 `dbUtils.delete(...)` |
 | `s_rule.b_scope_id` 为 `bigint`（v1 设计） | 实现为拼接串 `varchar(250)`；v2.0 已整体重新定义表结构，该差异随重建消除 |
 | 删除「先预览后确认」（设计 §4） | 列表页 `deleteSelected` 直接调 `saveObjectApi`，无预览/确认两步 |
 | `save.pre` / `b_hook` 预留位 | 只有 `delete.pre` 一种取值，预留位无实际内容 |
 
-**风险提示**：规则引擎未实现时，界面上配的删除规则**不生效**。这比没有该功能更危险——它给配置者虚假的安全感。详见 `FMS删除规则引擎设计.md`。
+**风险提示**：删除策略未实现时，界面上配置的删除规则**不生效**。这比没有该功能更危险——它给配置者虚假的安全感。详见 `FMS删除策略重构设计.md`。
 
 ---
 
 ## 七、建议的落地顺序
 
-1. **`s_relation` 加 `b_on_delete`**（四值、默认 `restrict`），配合 `FMS删除规则引擎设计.md` v2.0 的表结构调整；
-2. **模块管理分节改为「数据行为 / 访问控制」**，按业务问题而非载体划分；与删除规则前端改造（`FMS删除规则引擎设计.md` §8 步骤 5）同一批实施——两者都要动 `module-management/index.vue`，不单独安排；
-3. **`s_rule` 结构化**：显式 `b_kind`、直白 `b_module_id`、去掉预留位；
+1. **`s_relation` 加 `b_on_delete`**（三值、默认 `restrict`），按 `FMS删除策略重构设计.md` 的架构调整；
+2. **模块管理分节改为「数据行为 / 访问控制」**，按业务问题而非载体划分；删除策略统一为关联删除处理 + 删除 SQL 规则；
+3. **删除规则专用化**：使用 `s_delete_rule`，只保留模块、SQL、提示、启用和顺序；
 4. ~~补规范：明确中间表模块在模块树中的挂载位置~~ **已完成**：规范已写入 `FMS新系统核心表结构设计.md` §4.3；
 5. **实现后端删除引擎**（`deleteobj` + 检查器 + 执行器 + `saveobjt` 接入）。