REA模型详解：用资源、事件、代理重构业务数据建模

大概在两年前我第一次在某个企业资源计划项目里看到“REA”这个缩写时第一反应是某个开源框架的版本代号。后来跟着团队一起把老旧的会计模块翻新才真正意识到 REA 模型讨论的不是记账技巧而是“如何把一笔业务完整地变成数据”。今天我愿意把它拆开来讲一讲主要是想给正在做数据库设计、在 ERP 里维护会计模块、或者经常跟数据报表打交道的开发和运维一点可落地的参考。如果你刚接触这个概念也不用紧张我会尽量用一张订单从下单到收钱的全过程来说明问题。1. 先把 REA 的业务场景拉直资源、事件、代理到底怎么分1.1 用一张“卖保温杯”的订单说明三元素假设某公司卖出去十个保温杯单价四十元客户已经转账付清货款。一个传统记账系统里分录大概是“借银行存款四百贷主营业务收入四百”再补一张库存出库单就完事。可如果把这个流程放到 REA 模型里会先拆成三组东西资源保温杯这是有稀缺性、有经济价值的物品银行存款或者现金也是一类资源。事件销售事件、出库事件、收款事件它们是业务中真实发生的行为也是连接资源和代理之间的桥梁。代理客户、销售员、库管员、出纳这些参与事件的角色都在代理这一类里。REA 是 Resource-Event-Agent 三个英文词的首字母组合中文常叫资源事件代理模型。它的核心主张是业务数据不应该以“借贷科目”为骨架来组织而应该以“谁在哪个时间点对什么资源做了什么事”为骨架来组织。科目余额最后只是数据汇总的结果不是业务事实本身。1.2 为什么账上金额不能替代真实资源状态我遇到不少刚接触 REA 的同学会问既然最终都能算出钱和货为什么非要绕一圈这个问题的答案要从业务上的“黑洞期”说起。传统会计里借贷分录只能记录金额变化。比如收到客户转账以后系统里看到的是“银行存款增加四百”但你看不到这笔钱对应的是哪一次销售、哪一位客户、哪一批货。库存模块、销售模块、财务模块如果分开建设业务中间某个环节掉了账面上可能不差一分钱实物和往来却对不上。这个时候查账的人只能靠凭证编号、备注字段和 Excel 去反推当时的场景效率很低。REA 的思路是把“价值”和“责任”绑定在事件上。每一笔事件都清清楚楚地写了什么资源动了、动了多少、由谁发起、对谁负责。等到对账时不是在“科目余额”里找差异而是直接从“事件”路径上走一遍看是漏了出库、错记了单价还是收款没有关联到对应销售订单。这套逻辑更接近业务真相也更适合多人协作为主的复杂系统。注意REA 模型不是说“不要记账凭证”而是建议把实体资源状态、责任人、业务时间都当成数据建模的主题金额只是资源变化的一种度量口径。财务视角和管理视角在同一个事件下合并避免了两套系统互相矛盾。1.3 什么时候值得上 REA也不是每个系统都有必要完整上 REA。如果只是一个单机小收银软件一个月就几百张单传统借贷式反而更简单。但如果你遇到下面这些场景REA 的收益就非常明显业务链条里有库存、销售、采购、财务多个模块需要跨模块追踪权责经常被审计追问“这张出库单对应哪笔采购、这笔付款又对应哪张发票”需要完整业务血缘报表口径经常变今天看应收款、明天看客户贡献、后天看销售员提成不想每个指标都写一套独立逻辑。一句话当你发现业务人员反复在问“这笔钱到底从哪里来、要到哪去”REA 的建模方式能让回答从“查凭证”变成“查事件图谱”。2. 手把手建模从一张订单表单拆出记录、字段和键2.1 第一步把原始表单元素按类别归档我习惯先拿一张真实的业务单据放在桌面上比如销售单。一个销售单上通常有订单号、下单日期、客户名称、客户地址、商品名称、数量、单价、金额、销售员、仓库、备注。对着这张单子做归类时我会问自己三个问题这个东西是公司拥有的、有价值的东西吗是资源。这是一次完成的行为动作吗是事件。这是一个参与动作的人或部门吗是代理。按这个规则商品名称是资源客户和销售员是代理下单动作是事件。订单号乍一看是一个编号字段但它在 REA 里其实是“订单事件”的唯一标识客户地址不是独立资源而是客户代理的属性数量、单价、金额也不是独立资源它们是“事件-资源关联表”上的度量属性。下表是我常用的字段归类模板原始单据字段REA 归类建表位置商品名称、编码资源资源表单价、数量、金额资源事件的度量属性资源事件关联表客户、销售员代理代理表下单日期、出库日期、收款日期事件发生时间事件表订单号事件编号事件表主键或业务编号客户地址、电话代理属性代理属性表仓库资源或代理视建模粒度而定这个表格看着简单实际归类时最容易在“仓库”这里卡住。仓库可以理解成存放商品的资源也可以理解成一个管理商品的代理。我的建议是如果仓库需要核算单独的资源存放能力就让它作为资源如果仓库只用来表示“出库经手人”就让仓库管理员作为代理仓库本身只做成一个属性字段避免模型过度膨胀。2.2 第二步给事件命名并标出先后顺序事件命名是个容易忽视的细节。很多设计文档喜欢用中文口语名比如“卖货了”“发货了”“收到钱了”虽然团队内部能看懂但落到数据库表里容易产生歧义。更稳重的做法是统一成动词短语比如商品销售、商品出库、客户付款并且每个事件都要有明确的时点。事件的先后顺序决定了业务链条如何串联。一次完整的销售通常由几个事件组成客户下单事件仓库发货事件财务收款事件。这三个事件之间不是并列关系而是“触发链”。没有下单就没有发货要求没有交货金额就谈不上应收回款。在关系表里我们可以给每个事件加一个“前序事件编号”字段或者用一张事件间关联表来表达顺序。常见的建模方式是把“订单事件”放在最上游后续事件通过外键指向它。这里还有个实操关键点不要把业务状态混进事件里。比如“已发货”“已签收”“已付款”这些状态看上去像事件实际是多个事件核实后的结果。如果硬给一条订单记录加一个状态字段每次状态变化都要 UPDATE 这条记录最终的“更新时间”只能看到最后一次变化中间的多次节点全部丢失。REA 建议让每个节点成为独立事件用事件发生时间还原完整流程。2.3 第三步检查关系和维度的合法性REA 并不强制必须使用某套数据库关系但有几条基本规则值得遵守资源不能直接和代理挂钩。商品“属于”客户这种表达在 REA 里只能通过事件实现否则会造成权属修改无审计。事件和资源之间是“数量动”的关系通常要记录方向。出库对库存数量是减入库是增。销售事件对商品资源是减对应收账款所有权是增。事件和代理之间是“责任动”的关系。每个事件至少要有发起代理和接收代理没有代理参与的资源变动在业务上往往是不合法的。金额字段应该挂在“事件-资源关联”而非资源主表上。比如同一件商品在不同销售事件里的成交价可能不同单价属于事件事实不属于商品固定属性。检查完这些关系后模型基本就是稳定的。后续即使新增一个“售后换货事件”也不用改动原有的商品、客户、销售员表只需要新增事件类型和关联记录。3. 数据库落地拿得走的表结构和查询思路3.1 用五张基础表撑起一套最小 REA 系统概念厘清之后落地就不难了。大部分关系型数据库都可以用“代理表、资源表、事件表、两个关联表”这套结构起步。-- 代理表客户、供应商、内部人员都放这里 CREATE TABLE agent ( agent_id BIGINT PRIMARY KEY, agent_type VARCHAR(20) NOT NULL, -- customer/supplier/internal name VARCHAR(100) NOT NULL ); -- 资源表商品、现金、原材料等经济资源 CREATE TABLE resource ( resource_id BIGINT PRIMARY KEY, resource_type VARCHAR(30) NOT NULL, -- product/raw_material/cash name VARCHAR(100) NOT NULL, unit VARCHAR(20) ); -- 事件表只记录发生的事实 CREATE TABLE business_event ( event_id BIGINT PRIMARY KEY, event_type VARCHAR(30) NOT NULL, -- order/shipment/payment occurred_at TIMESTAMP NOT NULL, note VARCHAR(255) ); -- 事件-资源关联表记录资源变动的方向和数量 CREATE TABLE resource_event ( event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, direction VARCHAR(10) NOT NULL, -- in/out quantity DECIMAL(18,4) NOT NULL, unit_price DECIMAL(18,2), PRIMARY KEY (event_id, resource_id, direction), FOREIGN KEY (event_id) REFERENCES business_event(event_id), FOREIGN KEY (resource_id) REFERENCES resource(resource_id) ); -- 事件-代理关联表记录参与人及其角色 CREATE TABLE agent_event ( event_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, role VARCHAR(30) NOT NULL, -- seller/customer/warehouse PRIMARY KEY (event_id, agent_id, role), FOREIGN KEY (event_id) REFERENCES business_event(event_id), FOREIGN KEY (agent_id) REFERENCES agent(agent_id) );这个设计的好处是把“发生的事情”和“参与人员/资源变动”拆开。business_event不直接写商品、金额、客户这些字段所有业务属性全部通过关联表表达。于是任何一件资源都能被多个事件复用任何代理也能参与不同类型的事件模型非常灵活。以保温杯销售举例流程变成四行记录在business_event插入一条订单事件在resource_event插入一条保温杯 resources 出库记录方向为 out在resource_event插入一条现金资源入库记录方向为 in在agent_event分别插入客户、销售员的参与记录。有了这五张表一份订单对应的账务、库存、责任链路就全部可查。3.2 常用的三类查询怎么写第一类查询是“某个时间段某资源累计变动”。比如统计保温杯的销量SELECT r.name, SUM(CASE WHEN re.direction out THEN re.quantity ELSE 0 END) AS sold_qty, SUM(re.quantity * re.unit_price) AS sales_amount FROM resource_event re JOIN resource r ON r.resource_id re.resource_id JOIN business_event be ON be.event_id re.event_id WHERE r.resource_type product AND be.event_type shipment AND be.occurred_at :start_time AND be.occurred_at :end_time GROUP BY r.name;第二类查询是计算客户应收余额。核心思路是用销售金额减去已经收到的金额SELECT a.name, COALESCE(SUM(CASE WHEN be.event_type shipment THEN re.quantity * re.unit_price END), 0) AS delivered_amount, COALESCE(SUM(CASE WHEN be.event_type payment THEN re.quantity * re.unit_price END), 0) AS paid_amount, COALESCE(SUM(CASE WHEN be.event_type shipment THEN re.quantity * re.unit_price END), 0) - COALESCE(SUM(CASE WHEN be.event_type payment THEN re.quantity * re.unit_price END), 0) AS receivable_amount FROM agent_event ae JOIN agent a ON a.agent_id ae.agent_id JOIN business_event be ON be.event_id ae.event_id JOIN resource_event re ON re.event_id be.event_id WHERE a.agent_type customer GROUP BY a.name;第三类查询是查某个事件的所有参与对象和资源变动适合给业务人员画“订单流水图谱”SELECT be.event_id, be.event_type, be.occurred_at, re.direction, r.name AS resource_name, re.quantity, ag.name AS agent_name, ae.role FROM business_event be LEFT JOIN resource_event re ON re.event_id be.event_id LEFT JOIN resource r ON r.resource_id re.resource_id LEFT JOIN agent_event ae ON ae.event_id be.event_id LEFT JOIN agent ag ON ag.agent_id ae.agent_id WHERE be.event_id :current_event_id;这类联表查询刚写时觉得别扭但习惯后会发现它天然支持多视角报表。无论是按商品看按客户看还是按事件时间线看都是一套数据在服务不同口径不需要再额外维护一堆汇总表。3.3 金额和数量为什么要拆开存储我在早期设计里犯过一个错误把“金额”和“数量”放在同一张资源表里作为字段。后来发现商品单价经常变化同一客户不同订单的成交价可能完全不同甚至在同一个订单里不同行项单价也不一样。如果把“单价”挂在商品资源上就意味着改一处价格会污染所有历史订单。REA 的做法是把单价、数量作为事件资源关联表的度量属性。这样历史事件一旦生成就固定了不会因为商品当前价格调整而改变。库存资源只关心数量现金资源也可以只关心金额不同资源类型的度量天然独立。如果要核算库存金额查询时再把“数量乘当时单价”聚合起来而不是直接读一个“库存金额”字段。这个做法的额外好处是在做库存跌价、批次成本核算时能按事件序列重新计算不需要通过复杂的分摊逻辑回填历史数据。提示如果数据量特别大、报表实时性要求特别高可以在五张基础表之上再维护“汇总表”或“物化视图”但基础事件数据一定要保持原始、明细、不可丢。汇总层错了可以重算明细层错了才真的麻烦。4. 真实项目中踩过的坑和可以复用的避坑清单4.1 常见问题速查表问题典型症状常见原因建议解法事件表字段越来越多一张事件表里塞了订单号、地址、备注、税率、客户等级把事件当订单明细用而非当一个“发生点”业务属性尽量下沉到资源关联表和代理关联表状态更新丢失中间节点订单记录只有一个 status 字段看不到历史流转把流程状态当字段反复更新每个流转节点拆成独立事件库存单价对不上一张库存表同时维护数量和金额月底总对不平多次调价直接改了库存资源表单价只写在资源事件表里库存金额按事件汇总客户主体混淆同一客户在不同单据里名字不一样统计重复代理表缺少唯一标识和统一编码代理表单独维护并加客户唯一编码冲销逻辑混乱取消订单时直接 DELETE 原记录关联审计断链不理解事件不可变原则记录冲销事件或置失效标记保留原事件事件粒度不统一订单、发货、收款混在同一张表都用 event_type 区分却各自带不同字段建模没有统一事件粒度建议把事件类型做成字典相似粒度的事件共享一张表这些都是我在项目里实际见过的坑。其中“冲销逻辑混乱”最容易被轻视因为业务方往往会说“把这条数据删掉就行”。可在多系统集成环境下审计线索、对账链路、下游数据仓库都可能已经引用这条记录直接删除会造成难以追溯的空洞。保留原事件、新增一条反向事件才是更稳妥的做法。4.2 四条每天都会用到的设计原则第一事件只追加不修改。这不是教条而是为了可持续对账。哪怕录入金额错了也应该用“更正事件”弥补而不是直接 UPDATE 原事件号。这样业务的历史影像始终清楚排查问题时能区分“原始错误”和“后续修正”。第二关联表主键不要全盘使用自增主键。比如resource_event表如果用无意义的自增 ID反复 Join 时索引使用效率通常不够好还容易出现重复关联。用event_id resource_id direction做联合主键既能保证同一事件下同一资源不会出现两条相同方向记录又能直接加速查询。第三代理表里要维护“可追溯身份”。客户改公司名称、内部员工换部门都是常事代理表的唯一标识千万不能直接用姓名或名称字段否则改名后就失去同一主体身份。早期就分配稳定的代理编码表面看多一步后期省非常多麻烦。第四事件和资源关联的“方向”字段要用语义明确的枚举。in代表资源流入out代表资源流出。我看到过有的团队把方向写成/-看起来紧凑但时间一长就没人敢动聚合查询因为不知道加号是代表流入还是增加负债。明确枚举值可能要多次转换但换得一目了然。4.3 实施顺序上的建议如果你想把一套旧的会计系统改造为 REA不要一上来就全面推翻。建议先选一条核心业务链做试点比如采购到付款或者销售到回款。先按资源、事件、代理三张底稿把现有流程梳理清楚再小范围开发一套新表跟旧系统并行跑三个月。每一笔旧系统的凭证尝试用新模型的事件路径解释一遍。出现对不上的地方不是模型错了就是旧系统的原始凭证本身存在漏记或错记这反而是项目最有价值的发现。并行跑的阶段不要急着停掉旧报表。业务方对新模型不熟悉需要一段时间适应“事件流水”的查询习惯。等到核心业务流程在新模型里的查询性能、准确率、可解释性都稳定再逐步迁移正式报表。这个过程也给了团队消化建模逻辑的时间避免一次性切换带来的集体踩雷。个人在实际操作中最有体会的一点是REA 模型真正的门槛不是数据库技术而是克制住“把数据按人熟悉的表格样式存放”的冲动。人看到的是客户、商品、金额数据本身却需要事件和关联来承载逻辑。只要把业务发生点记录清楚后续无论是看应收、看库存、看销售员绩效还是做成本核算都只是不同查询路径的问题。若你正在为复杂的业务链路做系统设计不妨先在文档上画一张“资源、事件、代理”三列清单再把单据逐行填进去多半会有一种豁然开朗的感觉。