Appearance
架构总览
非常好，这一条我会完全按“系统架构说明书 / 内核设计稿”的标准来输出，目标是：
一眼看到结构 → 顺着箭头理解执行 → 能直接照着落表、写代码、拆模块
我会用 ASCII 架构图 + 分层表格 + 样例 的方式，全量展开。 （不再长篇口述，不再概念漂移）
一、总体全局视图（从 txn_journal 出发）
1️⃣ 全局资金处理总架构（ASCII 总图）
┌───────────────┐
│ Order 意图 │
│ t_unified_order│
└───────┬───────┘
│
校验 / 风控 / 路由 / 模板解析
│
▼
┌────────────────────┐
│ OrderAccountDetail │
│ 执行蓝图（非资金） │
└─────────┬──────────┘
│
资金执行引擎
│
┌─────────────────▼─────────────────┐
│ txn_journal │
│ ★ 唯一资金事实 / 不可变 ★ │
└─────────┬──────────┬─────────┬────┘
│ │ │
▼ ▼ ▼
余额结果 会计事实 流水表现
(account/balance) (acct_entry) (ledger/flow)
│ │ │
└────┬─────┴────┬────┘
▼ ▼
settlement trade_record
│
channel_settlement
│
银行关键结论
txn_journal是系统“宇宙中心”- 所有模块都是它的 派生视图
二、txn_journal 的精确职责与结构
2️⃣ txn_journal 的系统定位
【事实层】 txn_journal ← 真实发生
【结果层】 account/balance ← 计算结果
【表现层】 ledger/flow ← 查询展示❌ 它不是
- 订单
- 流水
- 会计分录
- 余额日志
✅ 它是
“这笔钱已经从 A 到 B，且不可否认”
3️⃣ txn_journal 核心字段（执行级）
t_txn_journal
────────────────────────────────────────
txn_no 全局唯一资金事实号
order_no 来源订单
biz_type PAY / REFUND / SUBSIDY
execute_type WALLET / BANK / CLEARING
from_subject_type USER / MERCHANT / PLAT
from_subject_id
to_subject_type
to_subject_id
amount
currency
execute_ref 执行引擎引用
occur_time 资金真实发生时间
status SUCCESS / REVERSED设计原则
- 不存余额
- 不存手续费
- 不存分润
- 只存 “发生了什么”
三、从 txn_journal 向外展开的模块全景
下面是你要求的 “全展开、无跳跃”。
4️⃣ 余额模块（Balance / Account）
角色
资金事实 → 账户状态
ASCII 流程
txn_journal
│
▼
账户定位（from / to）
│
▼
余额计算
│
├─ UPDATE t_account
└─ INSERT t_*_balance_change（可选）核心表
| 表 | 作用 |
|---|---|
| t_account | 当前余额 |
| t_user_balance_change | 用户余额轨迹 |
| t_plat_balance_change | 平台余额轨迹 |
样例
txn_journal:
USER(1001) → MERCHANT(2001) 100.00
结果：
t_account(USER 1001): -100
t_account(MERCHANT): +1005️⃣ 会计分录模块（Accounting Entry）
角色
资金事实 → 财务语言
ASCII 流程
txn_journal
│
▼
匹配会计规则
│
▼
生成借贷分录
│
▼
更新科目余额核心表
| 表 | 作用 |
|---|---|
| t_acct_events | 会计事件 |
| t_acct_entry | 借贷分录 |
| t_acct_ledger | 科目余额 |
样例（支付）
借：用户存款
贷：商户应收❗️全部是 POSTED ❌ 不再有 PENDING
6️⃣ 流水模块（Flow / Ledger）
角色
给“人”和“系统”看的钱路
ASCII 流程
txn_journal
│
├─ 用户视角 → t_user_account_ledger
├─ 平台视角 → t_plat_account_ledger
└─ 对外对账 → t_cross_system_ledger核心表
| 表 | 作用 |
|---|---|
| t_user_account_ledger | 用户流水 |
| t_plat_account_ledger | 平台流水 |
| t_txn_journal | 事实溯源 |
7️⃣ 交易记录模块（Trade）
角色
业务系统用的交易状态
ASCII
order + txn_journal
│
▼
trade_record核心表
| 表 | 作用 |
|---|---|
| t_user_trade_record | 用户 |
| t_plat_trade_record | 平台 |
8️⃣ Settlement（结算）
角色
决定“什么时候给钱”
ASCII
txn_journal（已归集）
│
▼
settlement_order
│
▼
settlement_detail核心用途
- 商户 T+1
- 延迟结算
- 代理结算
9️⃣ Channel Settlement（通道结算）
角色
决定“怎么把钱转出去”
ASCII
settlement_order
│
▼
channel_settlement
│
▼
银行批量执行核心表
| 表 | 作用 |
|---|---|
| channel_settlement | 通道执行 |
| channel_batch | 批次 |
| channel_reconcile | 对账 |
🔟 分润模块（Profit）
角色
分钱，但不碰钱
ASCII
txn_journal + settlement
│
▼
commission_record四、典型复杂场景抽象样例
示例 1：扫码支付 + 红包 + 平台补贴
USER → PLAT 10 （红包）
PLAT → MERCHANT 10
USER → MERCHANT 90= 3 条 txn_journal
示例 2：收单打包结算（套利）
交易发生：
USER → PLAT_CLEARING
结算日：
PLAT_CLEARING → MERCHANT✔ 平台账户成为 资金缓冲池
五、为什么这套“快 + 稳 + 可扩展”
| 问题 | 解法 |
|---|---|
| 快捷支付慢？ | 同步只到 txn_journal |
| 并发高？ | 执行引擎串行账户 |
| MQ 挂？ | txn_journal 可重放 |
| 规则变？ | 不影响历史事实 |
六、最终一句话总结（给架构评审用）
我们系统中只有一件事是真实的：txn_journal。 其余模块，都是它的视图。
如果你愿意，下一步我可以 直接给你：
- 📐 一张“可直接贴进设计文档”的 ASCII 总图（精简版）
- 🧱 txn_journal / settlement / channel 全套建表 SQL
- ⚙️ 执行引擎账户并发 & 锁模型
你现在已经不是“在问怎么设计”， 而是在 确认这是不是最终形态。
好，那我给你 ①「可直接贴进设计文档 / 架构评审用的 ASCII 精简总图」。 这一版目标是：一页看懂、不解释也能用、能对外讲清楚。
支付与资金处理系统总体架构图（精简·终版）
设计核心： txn_journal 是唯一资金事实源，其余均为派生结果
一、总体架构总图（精简 ASCII）
┌──────────────────────────────────────────────┐
│ Order 意图层 │
│ │
│ t_unified_order │
│ t_order_account_detail ← 执行蓝图（非资金）│
└───────────────┬──────────────────────────────┘
│
校验 / 风控 / 路由 / 模板
│
▼
┌──────────────────────────────────────────────┐
│ 资金执行引擎 (Execution) │
│ │
│ 幂等 / 锁 / 策略 / 重试 / 补偿 │
└───────────────┬──────────────────────────────┘
│
【执行成功后写入】
│
▼
┌──────────────────────────────────────────────┐
│ txn_journal ★资金事实层★ │
│ │
│ • from → to │
│ • amount / currency │
│ • execute_type (WALLET/BANK/CLEARING) │
│ • occur_time │
│ • status = SUCCESS │
│ │
│ ※ 不存余额 / 不存分润 / 不存手续费 │
└───────────────┬───────────────┬──────────────┘
│ │
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ 余额结果层 │ │ 会计事实层 │
│ │ │ │
│ t_account │ │ t_acct_events │
│ t_*_balance_change │ │ t_acct_entry │
│ │ │ t_acct_ledger │
└─────────┬───────────┘ └─────────┬───────────┘
│ │
▼ ▼
┌──────────────────────────────────────────────┐
│ 流水 / 表现层 │
│ │
│ t_user_account_ledger │
│ t_plat_account_ledger │
│ t_cross_system_ledger │
└───────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ 交易与结算层 │
│ │
│ t_user_trade_record │
│ t_plat_trade_record │
│ │
│ settlement_order / settlement_detail │
│ channel_settlement / channel_batch │
└───────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ 银行 / 外部系统 │
│ │
│ 批量清算 / 对账 / 回执 │
└──────────────────────────────────────────────┘二、这张图的“阅读说明”（给评审 / 同事）
1️⃣ 哪一层是同步必须完成的
Order → Execution → txn_journal✔ 快捷支付、扫码支付，只同步到 txn_journal
2️⃣ 哪些是异步派生
余额 / 会计 / 流水 / 结算 / 分润 / 对账✔ MQ / 调度 / 重放均可 ✔ 任意模块失败 ≠ 资金丢失
3️⃣ 哪一层是不可重建的
txn_journal4️⃣ 哪些是可删可算的
account / ledger / trade / settlement