模块划分

这一步你给的是**“真实工程级别”的完整细节**，已经不是概念设计了，所以我下面不会泛讲，而是直接站在“总账 / 资金中台 / 支付系统架构评审”的角度，帮你做三件事：

① 把 15 个模块重新“归位”到一条统一主干上② 明确：哪些是【事实表】、哪些是【过程表】、哪些是【结果/派生表】③ 点出你当前设计中「合理的」「可以收敛的」「需要警惕的」地方

我会严格基于你给的表，不凭空造表。

---

一、先给你一张「全体系事实分层总览图」（核心结论）

【一、业务与资金主事实层（Single Source of Truth）】
├── order              统一订单事实
├── trade              交易执行事实
├── accountingentry    会计事实（法律/财务）
├── flow               资金事实（钱是否动）

【二、账户与资金载体层（强一致核心）】
├── account            账户主数据 + 权益类子账
├── plat               平台账户（account 的特化）
├── account_credit / deposit / points / freeze
│   └── 账户权益子域（仍属于账户事实）

【三、执行 / 校验 / 编排层（过程，不是事实）】
├── executionengine
├── limit
├── paysafe
├── auth

【四、派生结果与经济关系层（可重算）】
├── balance
├── profit
├── agent

【五、外围支撑与治理层】
├── user
├── version

下面我们模块级拆解。

---

二、账户模块（account）——你这里设计得“非常像账务中台”

1️⃣ 模块真实定位（纠偏）

你现在给它的描述是：

管理账户及其余额、积分、授信等

但从表结构看，真实定位是：

“账户主数据 + 各类账户权益子账”

这是非常正确的方向 👍 说明你没有把所有东西硬塞进 balance 或 ledger。

---

2️⃣ 表的正确分层（这是关键）

✅【账户主事实】

表	角色
t_account	账户主事实（唯一）

✔ 账户是谁 ✔ 账户类型 ✔ 生命周期

---

✅【账户权益子域（仍是事实）】

这些表不是流水的替代品，而是“权益状态”：

子域	表
授信	t_account_credit
保证金	t_account_deposit
积分	t_account_points
冻结	t_account_freeze

👉 它们不是“派生”，而是“独立受控权益”

---

❌【权益流水（不要当主流水）】

表	定位
t_account_credit_txn	授信变化日志
t_account_points_txn	积分变化日志
t_account_freeze_txn	冻结变化日志

✔ 合理 ⚠ 但要明确：

这些是“子域内部流水”，不是资金主流水

---

⚠️【风险点提醒】

t_account_txn 这个表要非常谨慎：

• 如果它 = 账户级资金流水
• 那它和 flow 模块就有职责重叠风险

👉 正确姿势：

t_account_txn 只能作为 账户域的视图/索引表不能成为资金事实源

---

三、会计分录模块（accountingentry）——这是你体系里“最硬”的一层

1️⃣ 定位完全正确

你这套：

• event
• rule
• template
• entry
• ledger

是标准的“会计中台设计”。

---

2️⃣ 两种记账模式的正确边界

你这里非常专业，但我要帮你明确职责边界：

🔹 预记账模式

Order
  ↓
AcctEntry(PENDING)
  ↓
Freeze / Execute
  ↓
POSTED / CANCELLED

👉 余额冻结 = 账户层 👉 分录状态 = 会计层

不能混

---

🔹 事件驱动模式

外部事件
  ↓
AcctEvent
  ↓
AcctEntry(POSTED)

👉 不冻结 👉 不回滚，只能冲正

---

3️⃣ 关键原则（非常重要）

accountingentry 永远不直接改余额它只“宣告”账务事实

余额 = flow + balance 的事。

---

四、流水模块（flow）——你这里“该统一，但现在是分裂的”

1️⃣ 当前现状

表	问题
t_user_account_ledger	用户流水
t_plat_account_ledger	平台流水
t_cross_system_ledger	跨系统流水
t_txn_journal	生命周期日志

2️⃣ 架构级判断（重点）

资金流水在系统里只能有一个“事实源”

从你全体系看，这个角色应该是：

👉 t_txn_journal

---

3️⃣ 正确关系建议（不要求你现在就改）

t_txn_journal
  ├─ 用户账户视图 → t_user_account_ledger（派生/冗余）
  ├─ 平台账户视图 → t_plat_account_ledger（派生/冗余）
  └─ 外部对账视图 → t_cross_system_ledger（对账子集）

⚠️ 千万不要反过来 否则清算 / 对账 / 冲正一定会炸。

---

五、余额模块（balance）——这是典型“历史遗留拆分痕迹”

1️⃣ 当前设计的问题本质

表	问题
t_user_balance_change
t_plat_balance_change

这两个表说明一件事：

系统早期是“用户 / 平台两套资金视角”

---

2️⃣ 架构结论（非常明确）

余额变动不是主事实，只是“结果日志”

因此：

• ❌ 不应该成为资金依据
• ❌ 不应该参与清算
• ✅ 只能用于查询 / 展示 / 快速回溯

---

3️⃣ 正确归位

资金事实：t_txn_journal
余额结果：balance / account 表
余额日志：t_*_balance_change（可选）

---

六、executionengine ——你体系里的“交易发动机”

你这块非常成熟，但我要给你一句定性结论：

executionengine = Saga / Workflow 引擎

它不拥有任何资金事实

表的正确角色

表	定位
t_fund_execute_task	执行过程
t_fund_execute_entry	幂等
t_fund_execute_batch	批次
t_fund_execute_compensate	补偿
t_execution_strategy_*	策略

✔ 完全正确 ❌ 但不要和 flow / accounting 互相写数据

---

七、order 模块 ——你体系里的“总开关”

你的 order 模块已经是：

• 统一订单
• 费用模板
• 分账模板
• 路由模板

👉 这是**“交易蓝图层”**

正确职责边界

做	不做
定义参与账户	❌ 不改余额
定义费用规则	❌ 不落分润结果
定义分账模板	❌ 不直接生成流水

---

八、agent + profit ——这是“经济关系层”

正确定位（非常重要）

agent / profit 永远不直接碰资金

他们只做三件事：

1. 定义“谁有资格”
2. 定义“怎么分”
3. 产出“应得结果”

真正的钱：

profit  → 生成应付分润
          ↓
order / accounting / flow 执行

---

九、trade 模块 ——这是“业务视角的交易日志”

你这里的 user / plat trade record：

• ✅ 合理
• ❌ 不能作为账务 / 资金依据

它们是：

报表 & 对账的“业务镜像”

---

十、最终「模块 × 事实类型」矩阵（建议你直接存档）

模块	事实类型
order	业务事实
trade	执行事实
accountingentry	会计事实
flow	资金事实
account	账户事实
balance	派生结果
profit	派生结果
agent	规则关系
executionengine	过程
limit	校验
paysafe	风控
auth	治理
user	身份
version	运维

---

十一句「给你这个体系的终极评价」

你这套设计，已经不是“支付系统”， 而是“资金与账务中台雏形”。

你现在缺的不是模块，而是最后一刀“事实统一”。

---