我第一次看到“rea”这个项目代号时还以为是谁把 react 少敲了一个字母。直到进了项目群看了需求文档第一页才明白这里指的是 REA——一个在会计信息系统领域沉淀了几十年的业务建模思想。这套模型把我们从“凭证对不上、库存和财务打架、报表口径说不清”的泥潭里拉了出来。简单说REA 不是框架也不是中间件它是一套描述业务事实的方法论。它把企业里发生的每一笔经济活动拆成三个要素资源Resource、事件Event、参与者Agent用它们直接表达业务本质而不是一上来就写借贷分录。我们这次重构的是一个电商企业的核心交易与财务系统老系统里有三十多张报表、六种单据、三种对账口径业务和财务每个月对账都要人工调半天。用 REA 重新梳理之后所有单据、库存流水、应收应付全部统一到一套事件流水上问题一下子收敛了。这篇不是讲理论是把我们踩过的坑、画过的模型、写过的建表 SQL 和推导凭证的逻辑全部摊开。如果你也在做进销存、ERP、财务中台或者任何需要“业务和财务对齐”的系统这篇可以直接当参考。1. 项目背景与建模思路拆解1.1 老系统为什么让人头疼这个项目最开始不是重构是“救火”。业务方反馈的痛点有三个第一销售订单、出库单、收款单、发票各是各的流程数据散落在不同库里要对上一笔订单的收入和回款得跨四个系统手工拼第二财务每天人工核对进销存报表和凭证差异表永远有几十行查到最后大多是库存成本核算口径不一致第三业务想分析某个商品的真实利润财务说按移动加权平均算业务说按订单金额减采购成本算两边吵了半年。我们接手后发现老系统的数据模型是典型的“凭证驱动”一切围绕记账凭证展开先定义科目再定义凭证模板然后业务单据往凭证上映射。这种模型在单公司、单业态时还凑合一旦出现多仓、多公司、多业务模式并行凭证模板会暴涨每种业务组合都要一套规则维护成本高不说稍微改一个业务场景模板就崩。彼时项目组里有位做过审计系统的老同事提了一句“你们这堆表其实可以按 REA 重建。”当时大家一脸懵后来他把 1982 年那篇 REA 论文的核心思路讲了一遍我们才意识到老系统的问题不是代码烂而是从一开始就把“业务事实”和“会计表达”混在了一起。1.2 REA 模型的底层逻辑REA 的核心主张非常朴素数据库里最值得记录的不是“借什么贷什么”而是“发生了什么业务”。一笔销售业务本质上就是“商品资源流出企业、现金或应收账款资源流入企业”中间有一个或多个参与者客户、销售员参与。至于这笔业务该记主营业务收入还是记营业外收入、该借应收账款还是借银行存款那是会计规则层面的推导应该由系统在业务事件发生后自动生成而不是让业务人员去填。打个比方可能更好懂。传统凭证模型像拍电影时直接录“剪辑后的成片”剪辑师把素材剪成什么就是什么想换一个叙事视角就得重剪REA 模型像保留所有原始拍摄素材任何视角的成片都可以基于素材重新生成。我们做系统时需要“库存视角”“收入视角”“客户往来视角”传统模型要维护多套数据REA 只需要一套业务事件流水。REA 的三个核心概念具体到我们的电商业务里是这样的Resource资源库存商品、银行存款、应收账款、固定资产、服务工时都是企业拥有或控制的经济资源。Event事件影响资源增减的业务活动比如销售出库、采购入库、客户付款、供应商退款、内部领用。Agent参与者参与事件的人或组织包括内部参与者销售员、仓管员、采购员和外部参与者客户、供应商、承运商。事件不能单独存在它必须连接至少一个资源和至少一个参与者。这个约束保证了每一条业务数据都有完整的来龙去脉。1.3 为什么选择 REA 而不是继续补凭证模板我们也认真考虑过继续沿用凭证驱动、只是把模板做成可配置。后来放弃有两个原因。第一可配置模板解决不了“归因”问题。一笔订单退货可能是质量问题也可能是七天无理由还可能是因为物流破损拒收。不同原因对应的库存成本、责任归属、税费处理都不一样。模板驱动只能预先把这些分支写死而 REA 模型里这些都属于“退货事件”的补充属性分析时随时可以按维度切片。第二审计追溯要求我们从凭证能一路追到最原始的业务动作。凭证驱动模型下凭证就是源头但凭证本身是从业务单据转换来的追到凭证就算到底了原单据的信息被折叠掉了一部分。REA 模型下事件才是源头凭证只是事件的“派生视图”任何一个科目金额都能展开成一张真实发生的事件列表。这一点在 IPO 合规、外部审计时特别值钱。结论很明确核心账务和进销存部分完全按 REA 重建模外围的审批流、权限、发票管理保持原有体系只对齐事件编码。2. 核心模型拆解资源、事件、参与者怎么落地成表2.1 先把三个概念的边界界定清楚不少人在落地 REA 的时候会踩一个坑把所有东西都定义成“资源”把所有系统动作都定义成“事件”。我们内部给团队定的判断标准是资源必须是有数量或者金额价值、能进资产负债表项目的对象事件必须是改变资源状态的外部业务动作而不是系统内部操作。举几个反例“用户点击了下单按钮”这不是事件因为库存资源没有变化只有产生了“订单已提交”状态下单后真正锁定库存那一刻才算“库存预留事件”。“销售订单”本身不是资源它是记录事件和参与者关系的载体。订单里的每一个商品行、数量、单价本质是描述“销售事件”引起的“商品资源流出量”。“合同”也不是事件它是约束未来事件发生的协议。只有当合同被确认并产生交货行为时交货才算事件。这个界定标准花了我们一个礼拜。开发同学一开始总是觉得“订单”应该是一张表放在 REA 里似乎没有它的位置。后来我们明确订单头和订单行拆开订单行在 REA 里对应的是“订购事件OrderLineEvent”订单头对应的是“事件归组”因为它们共享同一批参与者、同一个合同约定、同一张发票。2.2 表结构怎么设计才不四不像我们不搞纯学术的极端范式每一张业务表仍然保留主键、创建时间、修改时间、操作人等公共字段但在领域核心部分严格按 REA 组织。最终核心表分成四组资源表resource 主表 resource_type 字典 resource_location资源在不同仓库的分布事件表event 主表 event_line事件明细 event_type 字典参与者表agent 主表 agent_role参与者在某个事件里的角色比如“买方”“卖方”“承运人”关系派生表由事件和资源、事件和参与者、事件和事件之间的关联自动生成不手工维护以销售和收款流程为例我们的核心建表语句简化成下面这样-- 资源表 CREATE TABLE resource ( id BIGINT PRIMARY KEY, resource_code VARCHAR(32) NOT NULL UNIQUE COMMENT 资源编码, resource_name VARCHAR(128) NOT NULL, resource_type VARCHAR(32) NOT NULL COMMENT PRODUCT/CASH/RECEIVABLE/EQUIPMENT, unit VARCHAR(16) DEFAULT NULL COMMENT 计量单位, status VARCHAR(16) NOT NULL DEFAULT ACTIVE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 事件主表 CREATE TABLE event ( id BIGINT PRIMARY KEY, event_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务事件编号, event_type VARCHAR(32) NOT NULL COMMENT SALES_PICK/PURCHASE_RECEIPT/PAYMENT/RECEIPT, event_time DATETIME NOT NULL COMMENT 业务发生时间, agent_id BIGINT NOT NULL COMMENT 发起方参与者, counter_agent_id BIGINT DEFAULT NULL COMMENT 对方参与者, location_id BIGINT DEFAULT NULL COMMENT 仓库/门店, doc_no VARCHAR(64) DEFAULT NULL COMMENT 关联原始单据号, status VARCHAR(16) NOT NULL DEFAULT PENDING, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 事件行明细一个事件可能影响多个资源 CREATE TABLE event_resource_line ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, quantity DECIMAL(18,4) NOT NULL COMMENT 正数为资源流入负数为资源流出, unit_cost DECIMAL(18,6) DEFAULT NULL COMMENT 移动均价或按比例分摊成本, amount DECIMAL(18,4) NOT NULL COMMENT 金额正负同quantity, FOREIGN KEY (event_id) REFERENCES event(id), FOREIGN KEY (resource_id) REFERENCES resource(id) ); -- 事件参与者角色同一个事件里客户、销售员、仓管员都是参与者 CREATE TABLE event_agent_role ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, role_type VARCHAR(32) NOT NULL COMMENT BUYER/SELLER/CREATOR/APPROVER/CARRIER, FOREIGN KEY (event_id) REFERENCES event(id), FOREIGN KEY (agent_id) REFERENCES agent(id) );这个结构最大的好处是业务上任何一笔真实发生的经济活动最终都能落到“事件主表 事件行明细 事件参与者角色”三张表上。查询收入、查询库存、查询往来余额全部基于同一套数据。2.3 事件如何串联起业务和财务事件之间天生存在“存量/流量”关系。一个业务链条里前一个事件的流出资源往往是后一个事件的流入资源。比如标准销售流程在 REA 里是这样串联的客户下单生成“订购事件”对应商品资源的“承诺流出”此时库存尚未减少只在事件行里记录订单数量和金额资源的 nonCommited 数量增加。仓库发货生成“销售出库事件”商品资源在 event_resource_line 里记录负数数量库存资源减少应收资源REA 里把应收看作资源同时通过派生逻辑增加。客户付款生成“收款事件”银行存款资源增加应收资源减少。内部记账系统根据这些事件实时推导出收入、成本、往来科目、库存价值的增减。整个过程中没有任何人手工填借贷科目。每一笔财务凭证都是从事件流水上自动生成的“投影”。我们甚至把“生成凭证”做成一个独立的异步任务事件发生先落库凭证生成可以在秒级完成但是系统对外承诺是“事件可见即最终一致”保证事件是事实、凭证是派生。3. 实操过程从业务梳理到系统落地3.1 第一步重新盘点业务事实而不是盘点业务单据项目启动的前两周我们没有写一行代码而是把所有业务部门拉在一起问一个特别基础的问题你们公司实际发生了哪些经济交换注意是“实际发生的交换”不是“你们系统里录了哪些单”。这一问现场就乱了。业务部门习惯按“单”汇报销售说我们有销售单、退货单仓库说有出库单、盘点单、调拨单财务说有收款单、付款单、发票。把“单”翻译成“事件”需要一层抽象销售单对应“订购事件”和“销售出库事件”退货单对应“销售退回事件”调拨单对应“资源转移事件”从一个仓调出、另一个仓调入其实是一个事件带两个资源行。我们列了一张事件清单最终收敛成十几个核心事件类型事件类型涉及资源典型参与者触发单据销售订购库存商品承诺客户、销售员销售订单销售出库库存商品减少、应收增加仓管员、客户出库单销售退回库存商品增加、应收减少仓管员、客户退货单采购收货库存商品增加、应付增加采购员、供应商收货单客户付款银行存款增加、应收减少财务、客户收款单供应商付款银行存款减少、应付减少财务、供应商付款单库存调拨库存商品一个仓减、一个仓增仓管员调拨单库存盘点库存商品调整仓管员盘点单这个清单出来之后我们发现很多老系统的“单据类型”其实只是同一个事件的不同视图。比如“销售退货”和“销售换货”在事件层面都是“销售退回事件 新的销售订购事件”只是数量上有差异。按事件建模以后不需要单独维护退货单的表结构只需要在事件上增加一个 return_reason 字段。3.2 第二步定义资源流向和事件派生规则事件清单确认之后我们给每个事件类型写了一张“派生规则卡”。规则卡描述这个事件发生以后哪些资源发生变化哪些会计科目要生成什么方向的金额。最复杂的规则是“销售出库 结转成本”。库存减少按什么计价我们选了移动加权平均因为比较接近老系统逻辑改动最小。每次商品入库事件更新 resource 上的当前平均成本出库事件读取当时的平均成本写入 event_resource_line 的 unit_cost。这个字段很关键因为后续所有收入匹配成本、库存价值核算都依赖它。再比如客户付款事件系统里可能同时存在多笔应收记录客户打过来一笔金额可能不够、可能是预收、可能覆盖多笔订单。传统做法是财务手工点“核销”REA 做法是把核销动作也建模成一个事件将“付款事件”和多个“应收资源减少事件”关联起来每一条关联都记录分配金额。这样核销的粒度、历史记录、调整记录全部留痕后面对账再也不怕“钱付了但不知道冲哪笔单”。3.3 第三步建表之后核心服务怎么拆模型定了表建了接下来要写代码。我们没有把整个系统做成一个大单体而是按领域拆了几个服务资源服务Resource Service管理商品、仓库、资金账户负责资源状态查询和可用量扣减。事件服务Event Service接受业务系统发来的事件消息做防重校验写 event 主表和明细表触发资源增减。凭证服务Ledger Service监听事件发布出来的消息异步生成会计凭证。报表查询服务Report Service直接查询事件仓库做各种维度的统计不依赖凭证表。事件服务是核心中的核心。它对外提供的不是 CRUD而是一个 method 风格接口postEvent(eventType, payload)。所有业务系统需要记业务事实时统一调用这个接口。这样做的好处是事件入湖口只有一条路径审计、监控、幂等可以集中在同一个地方处理。当时也有同事提出用消息队列解耦我们采用了。事件落库和派发消息是一个本地事务保证“数据库里事件存在MQ 一定发了”消息消费者做幂等防止重复派生。刚开始用同步调用高频场景下资源和事件的锁竞争太严重改成 MQ 后吞吐好很多。3.4 第四步用事件生成财务凭证凭证生成是 REA 落地最细节的部分。我们定义了一套“凭证模板规则引擎”每个事件类型对应一组借贷模板模板里的科目不是写死的而是从资源或者参与者上动态解析。举一例事件类型SALES_PICK借应收账款科目编码 1122 金额 事件行 amount 合计贷主营业务收入6001 金额 事件行 amount 合计借主营业务成本6401 金额 事件行 quantity × unit_cost贷库存商品1405 金额 事件行 quantity × unit_cost这样生成出来的凭证行项目数量比手工凭证多但它和事件一一对应任何一笔金额都能从凭证反查回事件再查回原始单据。审计时非常爽不用再玩“凭证-单据”匹配游戏。刚开始财务同事看到自动生成的凭证不习惯觉得“为什么收入确认是在出库事件而不是开票时”。我们解释了很久最终达成一致开票属于税务事件不影响收入确认收入确认跟着商品控制权转移走这本来就是会计准则层面的原则。4. 常见问题与排查技巧实录4.1 模型“太抽象”导致开发不知道怎么写代码这是落地过程中最大的反弹。很多后端开发拿到 REA 模型后第一反应是“这表怎么这么少业务逻辑写在哪”他们习惯了一个业务一块表的思路很难接受“所有业务都是事件”这种抽象。我们花了一周给团队培训核心就讲一句话写代码的人不要去想“销售单怎么保存”要想着“一次销售事件怎么被完整记录”。业务系统的控制流程下单、审核、发货、确认收货不是模型的一部分而是事件的流转状态机。每一张页面不再对应某一张表而是对应一个“事件的完整生命周期”。如果你也遇到团队不适应建议先从一条主链路开始试点不要一上来就切全部业务。我们选了“标准销售”和“标准采购”两条链路跑了三个月跑顺了再逐步加退货、换货、促销分摊、运费这些复杂场景。第一批模型稳定之后后面扩展新业务场景变得快得多。4.2 金额精度、扣减并发和幂等金额一律用 DECIMAL(18,4)禁止 FLOAT。我们一开始把税率、折扣、分摊后金额也统一放到 event_resource_line.amount四舍五入规则用 HALF_UP并且分摊差额在最后一个明细行做尾差修正。这些都是财务系统的老生常谈但因为它太基础反而容易在模型重构时被忽略。并发扣库存也是重灾区。商品资源上的可用量不能直接在行明细上做 update 减法因为多条事件并发时容易超卖。我们采用乐观锁 资源级分布式锁先尝试减少资源余额UPDATE resource_balance SET qty qty - #{qty} WHERE resource_id ? AND qty - #{qty} 0受影响行数为 0 就重试或者提示库存不足。同时每条事件有唯一 business key业务方传过来的 event_no事件服务按这个 key 做幂等重复推送的消息直接丢弃。4.3 REA 是不是要彻底抛弃会计科目当时财务内部也有疑虑你们搞这套玩意我总账科目怎么办管理报表怎么办其实 REA 从来不反对科目它反对的是把科目当作业务数据的源头。在我们的系统里科目体系依然完整保留只是科目余额不再通过“凭证积累”获得而由“事件派生”计算。总账余额表变成了一张“视图”底层是事件流水的聚合。对账的时候财务不再去核对凭证和报表差异而是核对“事件流水与原始单据是否一致”“凭证金额与事件金额是否一致”。前者靠事件服务保证后者靠凭证服务保证。这样对账范围大幅缩小而且任何不一致都能迅速定位到某一条具体事件上。4.4 查询性能优化和报表口径统一有人会担心把数据全部建模成事件报表查询会不会变慢确实会如果直接在主表上做多条件聚合几百万事件数据就能把数据库拖垮。我们的解法是“三层数据”事件库在线事务、事件宽表离线分析、聚合报表预计算。事件宽表每天同步一次报表查询走宽表实时性要求高的查询当天库存、当天销售额在事件库上走索引只查一天的数据量通常可以接受。月度销售分析全部走宽表用列式存储速度完全顶得住。报表口径统一这件事是 REA 送我们的一个大礼。以前“销售额”在老系统的三种统计口径开票口径、发货口径、下单口径都有独立代码实现现在全部基于事件类型过滤下单口径查“订购事件”发货口径查“销售出库事件”开票口径查“开票事件”。口径定义在系统里只有一处不可能再出现业务部门问“这个数怎么不对”的情况。4.5 权限、审核和审计追踪怎么处理REA 模型天然支持审计追踪每个事件都有 event_time、agent_id、role_type。权限系统我们做了两层页面操作权限仍然用传统 RBAC 管但关键资源比如库存扣减、应收调整的变更权限直接绑定到“是否允许发布某类事件”。审核流程比较好用的事件状态机实现。每个事件从“待提交”“审核中”“已生效”“已作废”流转对应不同的业务含义。特别注意的是“作废”不能直接把事件删除只能新增一个“冲正事件”方向取反。这样才能保证历史的每一次状态变化都有迹可循审计时不会被“删数据”这事吓到。刚开始开发习惯物理删除我们反复强调最后干脆在数据库层禁止 DELETE只允许 UPDATE 状态防止手滑。最后说点实在话这个项目做下来我最深的感受是每个老系统里都埋着一个“业务真相”但真相往往藏在几十张互相矛盾的报表下面。REA 最大的价值不是给你一套表结构而是逼着业务方和开发方回到最原始的“到底发生了什么”上来思考问题。踩过几次坑之后我现在在任何一个新项目里只要涉及业务和财务两套口径就会习惯性地先画一遍 REA 事件图。画完图闭眼就能看到哪些表必然存在、哪些字段必须保留、哪些报表将来要能生成。这比从界面上倒推表结构要省力太多。如果你也想在自己的系统里引入 REA我建议不要追求一步到位。先挑两个最核心的业务事件把事件表、资源表、凭证推导串通跑通以后再往周边扩展。先让一两条业务链路用起来远比设计一个理论上完美但没人能维护的大模型要实际。等到模型稳定了你会发现真正难的不是建模而是让所有人相信业务上发生的事情本身就应该成为系统的第一公民。
我第一次看到“rea”这个项目代号时还以为是谁把 react 少敲了一个字母。直到进了项目群看了需求文档第一页才明白这里指的是 REA——一个在会计信息系统领域沉淀了几十年的业务建模思想。这套模型把我们从“凭证对不上、库存和财务打架、报表口径说不清”的泥潭里拉了出来。简单说REA 不是框架也不是中间件它是一套描述业务事实的方法论。它把企业里发生的每一笔经济活动拆成三个要素资源Resource、事件Event、参与者Agent用它们直接表达业务本质而不是一上来就写借贷分录。我们这次重构的是一个电商企业的核心交易与财务系统老系统里有三十多张报表、六种单据、三种对账口径业务和财务每个月对账都要人工调半天。用 REA 重新梳理之后所有单据、库存流水、应收应付全部统一到一套事件流水上问题一下子收敛了。这篇不是讲理论是把我们踩过的坑、画过的模型、写过的建表 SQL 和推导凭证的逻辑全部摊开。如果你也在做进销存、ERP、财务中台或者任何需要“业务和财务对齐”的系统这篇可以直接当参考。1. 项目背景与建模思路拆解1.1 老系统为什么让人头疼这个项目最开始不是重构是“救火”。业务方反馈的痛点有三个第一销售订单、出库单、收款单、发票各是各的流程数据散落在不同库里要对上一笔订单的收入和回款得跨四个系统手工拼第二财务每天人工核对进销存报表和凭证差异表永远有几十行查到最后大多是库存成本核算口径不一致第三业务想分析某个商品的真实利润财务说按移动加权平均算业务说按订单金额减采购成本算两边吵了半年。我们接手后发现老系统的数据模型是典型的“凭证驱动”一切围绕记账凭证展开先定义科目再定义凭证模板然后业务单据往凭证上映射。这种模型在单公司、单业态时还凑合一旦出现多仓、多公司、多业务模式并行凭证模板会暴涨每种业务组合都要一套规则维护成本高不说稍微改一个业务场景模板就崩。彼时项目组里有位做过审计系统的老同事提了一句“你们这堆表其实可以按 REA 重建。”当时大家一脸懵后来他把 1982 年那篇 REA 论文的核心思路讲了一遍我们才意识到老系统的问题不是代码烂而是从一开始就把“业务事实”和“会计表达”混在了一起。1.2 REA 模型的底层逻辑REA 的核心主张非常朴素数据库里最值得记录的不是“借什么贷什么”而是“发生了什么业务”。一笔销售业务本质上就是“商品资源流出企业、现金或应收账款资源流入企业”中间有一个或多个参与者客户、销售员参与。至于这笔业务该记主营业务收入还是记营业外收入、该借应收账款还是借银行存款那是会计规则层面的推导应该由系统在业务事件发生后自动生成而不是让业务人员去填。打个比方可能更好懂。传统凭证模型像拍电影时直接录“剪辑后的成片”剪辑师把素材剪成什么就是什么想换一个叙事视角就得重剪REA 模型像保留所有原始拍摄素材任何视角的成片都可以基于素材重新生成。我们做系统时需要“库存视角”“收入视角”“客户往来视角”传统模型要维护多套数据REA 只需要一套业务事件流水。REA 的三个核心概念具体到我们的电商业务里是这样的Resource资源库存商品、银行存款、应收账款、固定资产、服务工时都是企业拥有或控制的经济资源。Event事件影响资源增减的业务活动比如销售出库、采购入库、客户付款、供应商退款、内部领用。Agent参与者参与事件的人或组织包括内部参与者销售员、仓管员、采购员和外部参与者客户、供应商、承运商。事件不能单独存在它必须连接至少一个资源和至少一个参与者。这个约束保证了每一条业务数据都有完整的来龙去脉。1.3 为什么选择 REA 而不是继续补凭证模板我们也认真考虑过继续沿用凭证驱动、只是把模板做成可配置。后来放弃有两个原因。第一可配置模板解决不了“归因”问题。一笔订单退货可能是质量问题也可能是七天无理由还可能是因为物流破损拒收。不同原因对应的库存成本、责任归属、税费处理都不一样。模板驱动只能预先把这些分支写死而 REA 模型里这些都属于“退货事件”的补充属性分析时随时可以按维度切片。第二审计追溯要求我们从凭证能一路追到最原始的业务动作。凭证驱动模型下凭证就是源头但凭证本身是从业务单据转换来的追到凭证就算到底了原单据的信息被折叠掉了一部分。REA 模型下事件才是源头凭证只是事件的“派生视图”任何一个科目金额都能展开成一张真实发生的事件列表。这一点在 IPO 合规、外部审计时特别值钱。结论很明确核心账务和进销存部分完全按 REA 重建模外围的审批流、权限、发票管理保持原有体系只对齐事件编码。2. 核心模型拆解资源、事件、参与者怎么落地成表2.1 先把三个概念的边界界定清楚不少人在落地 REA 的时候会踩一个坑把所有东西都定义成“资源”把所有系统动作都定义成“事件”。我们内部给团队定的判断标准是资源必须是有数量或者金额价值、能进资产负债表项目的对象事件必须是改变资源状态的外部业务动作而不是系统内部操作。举几个反例“用户点击了下单按钮”这不是事件因为库存资源没有变化只有产生了“订单已提交”状态下单后真正锁定库存那一刻才算“库存预留事件”。“销售订单”本身不是资源它是记录事件和参与者关系的载体。订单里的每一个商品行、数量、单价本质是描述“销售事件”引起的“商品资源流出量”。“合同”也不是事件它是约束未来事件发生的协议。只有当合同被确认并产生交货行为时交货才算事件。这个界定标准花了我们一个礼拜。开发同学一开始总是觉得“订单”应该是一张表放在 REA 里似乎没有它的位置。后来我们明确订单头和订单行拆开订单行在 REA 里对应的是“订购事件OrderLineEvent”订单头对应的是“事件归组”因为它们共享同一批参与者、同一个合同约定、同一张发票。2.2 表结构怎么设计才不四不像我们不搞纯学术的极端范式每一张业务表仍然保留主键、创建时间、修改时间、操作人等公共字段但在领域核心部分严格按 REA 组织。最终核心表分成四组资源表resource 主表 resource_type 字典 resource_location资源在不同仓库的分布事件表event 主表 event_line事件明细 event_type 字典参与者表agent 主表 agent_role参与者在某个事件里的角色比如“买方”“卖方”“承运人”关系派生表由事件和资源、事件和参与者、事件和事件之间的关联自动生成不手工维护以销售和收款流程为例我们的核心建表语句简化成下面这样-- 资源表 CREATE TABLE resource ( id BIGINT PRIMARY KEY, resource_code VARCHAR(32) NOT NULL UNIQUE COMMENT 资源编码, resource_name VARCHAR(128) NOT NULL, resource_type VARCHAR(32) NOT NULL COMMENT PRODUCT/CASH/RECEIVABLE/EQUIPMENT, unit VARCHAR(16) DEFAULT NULL COMMENT 计量单位, status VARCHAR(16) NOT NULL DEFAULT ACTIVE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 事件主表 CREATE TABLE event ( id BIGINT PRIMARY KEY, event_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务事件编号, event_type VARCHAR(32) NOT NULL COMMENT SALES_PICK/PURCHASE_RECEIPT/PAYMENT/RECEIPT, event_time DATETIME NOT NULL COMMENT 业务发生时间, agent_id BIGINT NOT NULL COMMENT 发起方参与者, counter_agent_id BIGINT DEFAULT NULL COMMENT 对方参与者, location_id BIGINT DEFAULT NULL COMMENT 仓库/门店, doc_no VARCHAR(64) DEFAULT NULL COMMENT 关联原始单据号, status VARCHAR(16) NOT NULL DEFAULT PENDING, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 事件行明细一个事件可能影响多个资源 CREATE TABLE event_resource_line ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, quantity DECIMAL(18,4) NOT NULL COMMENT 正数为资源流入负数为资源流出, unit_cost DECIMAL(18,6) DEFAULT NULL COMMENT 移动均价或按比例分摊成本, amount DECIMAL(18,4) NOT NULL COMMENT 金额正负同quantity, FOREIGN KEY (event_id) REFERENCES event(id), FOREIGN KEY (resource_id) REFERENCES resource(id) ); -- 事件参与者角色同一个事件里客户、销售员、仓管员都是参与者 CREATE TABLE event_agent_role ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, role_type VARCHAR(32) NOT NULL COMMENT BUYER/SELLER/CREATOR/APPROVER/CARRIER, FOREIGN KEY (event_id) REFERENCES event(id), FOREIGN KEY (agent_id) REFERENCES agent(id) );这个结构最大的好处是业务上任何一笔真实发生的经济活动最终都能落到“事件主表 事件行明细 事件参与者角色”三张表上。查询收入、查询库存、查询往来余额全部基于同一套数据。2.3 事件如何串联起业务和财务事件之间天生存在“存量/流量”关系。一个业务链条里前一个事件的流出资源往往是后一个事件的流入资源。比如标准销售流程在 REA 里是这样串联的客户下单生成“订购事件”对应商品资源的“承诺流出”此时库存尚未减少只在事件行里记录订单数量和金额资源的 nonCommited 数量增加。仓库发货生成“销售出库事件”商品资源在 event_resource_line 里记录负数数量库存资源减少应收资源REA 里把应收看作资源同时通过派生逻辑增加。客户付款生成“收款事件”银行存款资源增加应收资源减少。内部记账系统根据这些事件实时推导出收入、成本、往来科目、库存价值的增减。整个过程中没有任何人手工填借贷科目。每一笔财务凭证都是从事件流水上自动生成的“投影”。我们甚至把“生成凭证”做成一个独立的异步任务事件发生先落库凭证生成可以在秒级完成但是系统对外承诺是“事件可见即最终一致”保证事件是事实、凭证是派生。3. 实操过程从业务梳理到系统落地3.1 第一步重新盘点业务事实而不是盘点业务单据项目启动的前两周我们没有写一行代码而是把所有业务部门拉在一起问一个特别基础的问题你们公司实际发生了哪些经济交换注意是“实际发生的交换”不是“你们系统里录了哪些单”。这一问现场就乱了。业务部门习惯按“单”汇报销售说我们有销售单、退货单仓库说有出库单、盘点单、调拨单财务说有收款单、付款单、发票。把“单”翻译成“事件”需要一层抽象销售单对应“订购事件”和“销售出库事件”退货单对应“销售退回事件”调拨单对应“资源转移事件”从一个仓调出、另一个仓调入其实是一个事件带两个资源行。我们列了一张事件清单最终收敛成十几个核心事件类型事件类型涉及资源典型参与者触发单据销售订购库存商品承诺客户、销售员销售订单销售出库库存商品减少、应收增加仓管员、客户出库单销售退回库存商品增加、应收减少仓管员、客户退货单采购收货库存商品增加、应付增加采购员、供应商收货单客户付款银行存款增加、应收减少财务、客户收款单供应商付款银行存款减少、应付减少财务、供应商付款单库存调拨库存商品一个仓减、一个仓增仓管员调拨单库存盘点库存商品调整仓管员盘点单这个清单出来之后我们发现很多老系统的“单据类型”其实只是同一个事件的不同视图。比如“销售退货”和“销售换货”在事件层面都是“销售退回事件 新的销售订购事件”只是数量上有差异。按事件建模以后不需要单独维护退货单的表结构只需要在事件上增加一个 return_reason 字段。3.2 第二步定义资源流向和事件派生规则事件清单确认之后我们给每个事件类型写了一张“派生规则卡”。规则卡描述这个事件发生以后哪些资源发生变化哪些会计科目要生成什么方向的金额。最复杂的规则是“销售出库 结转成本”。库存减少按什么计价我们选了移动加权平均因为比较接近老系统逻辑改动最小。每次商品入库事件更新 resource 上的当前平均成本出库事件读取当时的平均成本写入 event_resource_line 的 unit_cost。这个字段很关键因为后续所有收入匹配成本、库存价值核算都依赖它。再比如客户付款事件系统里可能同时存在多笔应收记录客户打过来一笔金额可能不够、可能是预收、可能覆盖多笔订单。传统做法是财务手工点“核销”REA 做法是把核销动作也建模成一个事件将“付款事件”和多个“应收资源减少事件”关联起来每一条关联都记录分配金额。这样核销的粒度、历史记录、调整记录全部留痕后面对账再也不怕“钱付了但不知道冲哪笔单”。3.3 第三步建表之后核心服务怎么拆模型定了表建了接下来要写代码。我们没有把整个系统做成一个大单体而是按领域拆了几个服务资源服务Resource Service管理商品、仓库、资金账户负责资源状态查询和可用量扣减。事件服务Event Service接受业务系统发来的事件消息做防重校验写 event 主表和明细表触发资源增减。凭证服务Ledger Service监听事件发布出来的消息异步生成会计凭证。报表查询服务Report Service直接查询事件仓库做各种维度的统计不依赖凭证表。事件服务是核心中的核心。它对外提供的不是 CRUD而是一个 method 风格接口postEvent(eventType, payload)。所有业务系统需要记业务事实时统一调用这个接口。这样做的好处是事件入湖口只有一条路径审计、监控、幂等可以集中在同一个地方处理。当时也有同事提出用消息队列解耦我们采用了。事件落库和派发消息是一个本地事务保证“数据库里事件存在MQ 一定发了”消息消费者做幂等防止重复派生。刚开始用同步调用高频场景下资源和事件的锁竞争太严重改成 MQ 后吞吐好很多。3.4 第四步用事件生成财务凭证凭证生成是 REA 落地最细节的部分。我们定义了一套“凭证模板规则引擎”每个事件类型对应一组借贷模板模板里的科目不是写死的而是从资源或者参与者上动态解析。举一例事件类型SALES_PICK借应收账款科目编码 1122 金额 事件行 amount 合计贷主营业务收入6001 金额 事件行 amount 合计借主营业务成本6401 金额 事件行 quantity × unit_cost贷库存商品1405 金额 事件行 quantity × unit_cost这样生成出来的凭证行项目数量比手工凭证多但它和事件一一对应任何一笔金额都能从凭证反查回事件再查回原始单据。审计时非常爽不用再玩“凭证-单据”匹配游戏。刚开始财务同事看到自动生成的凭证不习惯觉得“为什么收入确认是在出库事件而不是开票时”。我们解释了很久最终达成一致开票属于税务事件不影响收入确认收入确认跟着商品控制权转移走这本来就是会计准则层面的原则。4. 常见问题与排查技巧实录4.1 模型“太抽象”导致开发不知道怎么写代码这是落地过程中最大的反弹。很多后端开发拿到 REA 模型后第一反应是“这表怎么这么少业务逻辑写在哪”他们习惯了一个业务一块表的思路很难接受“所有业务都是事件”这种抽象。我们花了一周给团队培训核心就讲一句话写代码的人不要去想“销售单怎么保存”要想着“一次销售事件怎么被完整记录”。业务系统的控制流程下单、审核、发货、确认收货不是模型的一部分而是事件的流转状态机。每一张页面不再对应某一张表而是对应一个“事件的完整生命周期”。如果你也遇到团队不适应建议先从一条主链路开始试点不要一上来就切全部业务。我们选了“标准销售”和“标准采购”两条链路跑了三个月跑顺了再逐步加退货、换货、促销分摊、运费这些复杂场景。第一批模型稳定之后后面扩展新业务场景变得快得多。4.2 金额精度、扣减并发和幂等金额一律用 DECIMAL(18,4)禁止 FLOAT。我们一开始把税率、折扣、分摊后金额也统一放到 event_resource_line.amount四舍五入规则用 HALF_UP并且分摊差额在最后一个明细行做尾差修正。这些都是财务系统的老生常谈但因为它太基础反而容易在模型重构时被忽略。并发扣库存也是重灾区。商品资源上的可用量不能直接在行明细上做 update 减法因为多条事件并发时容易超卖。我们采用乐观锁 资源级分布式锁先尝试减少资源余额UPDATE resource_balance SET qty qty - #{qty} WHERE resource_id ? AND qty - #{qty} 0受影响行数为 0 就重试或者提示库存不足。同时每条事件有唯一 business key业务方传过来的 event_no事件服务按这个 key 做幂等重复推送的消息直接丢弃。4.3 REA 是不是要彻底抛弃会计科目当时财务内部也有疑虑你们搞这套玩意我总账科目怎么办管理报表怎么办其实 REA 从来不反对科目它反对的是把科目当作业务数据的源头。在我们的系统里科目体系依然完整保留只是科目余额不再通过“凭证积累”获得而由“事件派生”计算。总账余额表变成了一张“视图”底层是事件流水的聚合。对账的时候财务不再去核对凭证和报表差异而是核对“事件流水与原始单据是否一致”“凭证金额与事件金额是否一致”。前者靠事件服务保证后者靠凭证服务保证。这样对账范围大幅缩小而且任何不一致都能迅速定位到某一条具体事件上。4.4 查询性能优化和报表口径统一有人会担心把数据全部建模成事件报表查询会不会变慢确实会如果直接在主表上做多条件聚合几百万事件数据就能把数据库拖垮。我们的解法是“三层数据”事件库在线事务、事件宽表离线分析、聚合报表预计算。事件宽表每天同步一次报表查询走宽表实时性要求高的查询当天库存、当天销售额在事件库上走索引只查一天的数据量通常可以接受。月度销售分析全部走宽表用列式存储速度完全顶得住。报表口径统一这件事是 REA 送我们的一个大礼。以前“销售额”在老系统的三种统计口径开票口径、发货口径、下单口径都有独立代码实现现在全部基于事件类型过滤下单口径查“订购事件”发货口径查“销售出库事件”开票口径查“开票事件”。口径定义在系统里只有一处不可能再出现业务部门问“这个数怎么不对”的情况。4.5 权限、审核和审计追踪怎么处理REA 模型天然支持审计追踪每个事件都有 event_time、agent_id、role_type。权限系统我们做了两层页面操作权限仍然用传统 RBAC 管但关键资源比如库存扣减、应收调整的变更权限直接绑定到“是否允许发布某类事件”。审核流程比较好用的事件状态机实现。每个事件从“待提交”“审核中”“已生效”“已作废”流转对应不同的业务含义。特别注意的是“作废”不能直接把事件删除只能新增一个“冲正事件”方向取反。这样才能保证历史的每一次状态变化都有迹可循审计时不会被“删数据”这事吓到。刚开始开发习惯物理删除我们反复强调最后干脆在数据库层禁止 DELETE只允许 UPDATE 状态防止手滑。最后说点实在话这个项目做下来我最深的感受是每个老系统里都埋着一个“业务真相”但真相往往藏在几十张互相矛盾的报表下面。REA 最大的价值不是给你一套表结构而是逼着业务方和开发方回到最原始的“到底发生了什么”上来思考问题。踩过几次坑之后我现在在任何一个新项目里只要涉及业务和财务两套口径就会习惯性地先画一遍 REA 事件图。画完图闭眼就能看到哪些表必然存在、哪些字段必须保留、哪些报表将来要能生成。这比从界面上倒推表结构要省力太多。如果你也想在自己的系统里引入 REA我建议不要追求一步到位。先挑两个最核心的业务事件把事件表、资源表、凭证推导串通跑通以后再往周边扩展。先让一两条业务链路用起来远比设计一个理论上完美但没人能维护的大模型要实际。等到模型稳定了你会发现真正难的不是建模而是让所有人相信业务上发生的事情本身就应该成为系统的第一公民。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
