04 ｜ 结算规则引擎与分账模型

让规则「可配置」而非「硬编码」——佣金、扣款、分账怎么不每次改代码

一、分账的本质：一笔订单的钱怎么分

一笔订单收了消费者 100 元，这笔钱不会全部给商家。平台扣佣金、推广方拿返佣、供应商拿采购价、商家拿剩余——这就是分账。分账规则的本质，就是定义「钱在平台、商家、供应商、推广方之间怎么切」。

上图中每一笔分账金额，都不是写死的——它由规则决定：佣金率 5% 是规则，推广返佣率 3% 是规则，平台承担优惠券金额也是规则。规则变了，分账结果就变了。如果这些规则散落在代码里，每改一次都要走开发流程，效率极低且容易出错。

二、规则要素拆解：把规则变成「结构化数据」

一条分账规则不管多复杂，拆到底就是五个要素：计算基数、费率、阶梯、封顶、减免。把这五个要素结构化表达出来，规则就变成了数据，而不是代码。

举个例子，一条「大促阶梯佣金规则」的结构化表达：

三、规则引擎设计：配置 → 编译 → 执行

结构化解决了「规则怎么存」，但规则从配置到最终算出金额，要经过三个阶段。这就是规则引擎的三层架构。

三层各自的职责：

- 配置层：运营在后台操作，选要素、设条件、定时间。这一层只管「输入」，不碰计算逻辑。

- 编译层：系统把配置数据校验、解析成可执行的计算逻辑，并生成规则快照——也就是当前规则版本的完整副本，不可修改。

- 执行层：每笔订单过来，匹配适用规则，按要素逐项算出分账明细，并记下用的是哪个版本的规则。

四、结算单生成：订单 + 规则 → 结算明细 → 汇总

规则引擎算出的是单笔订单的分账明细，而结算单是一批订单的汇总。从明细到结算单，是一个「先算每笔、再汇总成单」的推导过程。

这个推导链路的关键设计点：

- 明细不可篡改：结算明细在订单完成时就算好了，结算单只是汇总。改规则不影响已生成的明细，只影响之后的新订单。

- 汇总维度可配：按商家汇总出商家结算单，按供应商汇总出应付单，按推广方汇总出佣金单——同一批明细，不同切法。

- 规则版本随单留存：每条结算明细都记录当时使用的规则版本号，结算单可追溯到每笔明细用了哪版规则。

五、规则版本管理：变更可追溯

规则一定会变——费率调了、活动上了、合同改了。版本管理要解决的问题是：规则变了之后，历史的结算单还能不能说清楚当时是按什么规则算的。

举个真实场景：商家投诉 3 月佣金多扣了。平台回溯发现 3 月 15 日佣金率从 5% 改到了 4%，但 3 月 1-14 日的订单按 5% 算的——没问题。再看明细，3 月 20 日有一笔大单，系统匹配的是 v2.0 规则（5%），而不是当时应该生效的 v2.1（4%）。原因找到了：规则编译时版本锁定有 bug。

六、规则引擎的本质

规则引擎的本质，是把「改代码」变成「改配置」。
业务跑得快，系统才扛得住。