REA模型实战：用资源-事件-参与者重构进销存对账难题

我第一次听到 REA 这三个字母时，其实是有点排斥的。那会儿我们正给一家食品供应链公司做进销存重构，财务和仓库连着三周对不上数，仓库说按吨入的，财务说按金额记的，两边各抱一份 Excel 谁也不让步。后来真正把 REA 模型用进项目，我才发现过去纠结的“单据怎么管、库存怎么记、往来账怎么对”，本质上缺的是一张能串起所有业务动作的网。这篇文章不是教科书式的理论复述，而是一次真实重构的复盘。我会把 REA 拆开揉碎，结合具体的采购销售案例，讲清楚它解决了什么问题、落地时表怎么建、状态怎么管，以及我们迁移老系统时踩过的几个大坑。无论你是在做 ERP、财务中台，还是普通业务系统的库存模块，只要遇到过“账对不上”的场面，这文章应该能给你一些启发。

1. REA 到底是什么——从一次进销存改造谈起

1.1 三要素：Resource、Event、Agent

REA 是 Resource-Event-Agent 的缩写，中文一般叫“资源-事件-参与者”模型。它最初是针对传统会计信息系统提出的一套领域建模思路，核心思想特别朴素：业务系统不应该围绕单据来设计，而应该围绕“资源如何变化、由什么事件触发、由谁参与”来设计。

三个概念一个一个说。

Resource（资源）不是泛指一切东西，而是指有价值、能被追踪、会发生变化的经济对象。库存里的咖啡豆是资源，账户里的现金是资源，对客户的一笔应收账款也是资源。注意，订单本身不是资源，它只是流程凭证。Resource 的核心特征是“可以计量、可以增减、有期初余额和期末余额”。

Event（事件）是改变资源状态的经济行为。采购入库让库存增加，这就是一个事件；销售出库让库存减少，这也是一个事件；客户转账进来让现金增加，同样是事件。事件的核心特征是不可变性，一旦发生就不应该被修改，只有这样才能追溯历史。

Agent（参与者）是参与事件的个人或组织，包括企业内部的人（采购员、仓管员）和企业外部的实体（供应商、客户）。Agent 解决的是“谁负责、谁授权、谁受益”的问题。

我们当时做了一个很粗糙的类比：资源是演员手里的道具，事件是剧本里的动作，Agent 是动作的发出者。单据只是导演手里的场记板，它记录场景，但真正推动剧情的是动作本身。

1.2 三条链接规则：增减、授权、对偶

光有三要素还不够，REA 的价值在于把要素之间的关系固化成规则。我们项目里只强制落地了三条规则。

第一条，每个 Event 必须至少影响一个 Resource，要么让它增，要么让它减。一个采购入库事件，必然让库存资源增加；一个付款事件，必然让现金资源减少。如果某个事件说不清影响了哪个资源，那它就不配叫经济事件，很可能只是系统里的一个操作动作。

第二条，每个 Event 必须被至少一个 Agent 授权或参与。授权解决责任问题，谁同意这笔采购，谁执行这批入库，谁是收款方。我们把“经办人”和“外部往来单位”拆开存，避免一个问题：一个销售单可能有多个经手人，但客户始终只有一个。

第三条，每个 Event 最好能找到它的经济对偶（Economic Duality）。这是 REA 里最容易被忽略、但恰恰是防止账目混乱的关键。采购入库的“资源增加”事件，要和后续“付款”的资源减少事件配对；销售出库的“资源减少”事件，要和后续“收款”的资源增加事件配对。简单说，一件事发生之后，必然存在一个对应的补偿性事件，这个成对关系才是账目平衡的真正来源。

传统复式记账用“借贷必相等”保证平衡，REA 用“事件对偶链”保证平衡。两者解决的问题一样，但 REA 更贴近业务语言，非会计背景的开发也能看懂。

1.3 为什么比“单据加借贷账”更贴近现实

我们当时最大的痛点是：采购部用采购订单，仓库用入库单，财务用发票和付款单，三套系统各有各的单号，一旦某个环节漏单，整条链就断了。REA 改变了“事实”的定义——事实不是哪张单，而是资源在那个时间点因为哪个事件变了多少。

下面是我们在评审会上给管理层展示的对比，挺直观：

这套对比后来成了我们说服业务方的主要材料。业务方听不懂“资源事件参与者”，但听得懂“以后库存和应收不再各算各的”。REA 不是银弹，但它天然把“多个系统各自记账”改成“一个事实多重投影”，这正是当时我们最需要的东西。

2. 业务流程如何翻译成 REA 模型

2.1 用一个咖啡豆案例拆解全过程

理论讲十遍，不如走一个完整案例。我们当时选了一个咖啡豆采购销售链路做试点，业务足够典型，又不算太复杂。

公司向供应商 A 采购咖啡豆，之后卖给客户 B。如果按传统单据流，这中间至少有采购订单、入库单、发票、付款单、销售订单、出库单、收款单七种单据。用 REA 重写，只剩四组核心事件：

1. 采购入库事件：咖啡豆库存增加（Resource increment），参与者是采购员和供应商 A，时间点是实际到货日。
2. 付款给供应商事件：现金减少（Resource decrement），同时形成对供应商的付款义务清偿，经济对偶是前面那笔采购入库。
3. 销售出库事件：咖啡豆库存减少（Resource decrement），同时形成对客户 B 的应收账款增加（Resource increment）。
4. 客户回款事件：现金增加（Resource increment），应收账款减少，经济对偶是前面那笔销售出库。

我们甚至用这套模型做了一次手工推演。假设期初库存为 0，第一笔采购 100 公斤，单价 80 元；第二笔采购 100 公斤，单价 100 元；随后销售 50 公斤。按移动加权平均法算，第一笔后库存金额 8000 元；第二笔后库存总金额 18000 元，平均单价 90 元；销售出库 50 公斤，结转成本 4500 元，库存剩余 150 公斤，金额 13500 元。

旧系统里这组数字散落在三张表里，入库单记数量、发票记金额、付款单记实际付款，对账全靠人工勾稽。REA 版本里，所有数字都由同一条事件链推导出来，增量和减量事件挂在同一个 Resource 上，天然不会出现“库存数量这边加了、财务金额那边没加”的错位。

2.2 建模中的四个边界问题

实操中大家问得最多的问题是：到底什么事情才适合建模成 Resource、Event、Agent？我们总结了四个边界判断，基本上能解决八成困惑。

资源边界：只有能计量、有余额、需要被跟踪的对象才算资源。库存、现金、应收账款、应付账款是对的；合同文本、订单编号、审批记录不对，它们只是上下文。如果团队争执不下，就问一句：这个对象能算期末余额吗？不能算，基本就不适合当资源。

事件边界：只有真正改变资源状态的动作才算事件。客户下了订单，库存变了吗？没有。所以订单创建不是经济事件；订单审核通过，库存变了吗？还是没有。所以审核也不是经济事件。采购到货、销售发货、收到货款，这些才是。我们见过很多团队把状态流转的每一步都建模成 Event，最后事件表里塞满了“草稿创建”“已提交”这类噪音，聚合查询时痛苦不堪。

代理边界：Agent 必须是经济参与者，而不是系统用户。采购部的张三是一个内部 Agent，但他代表公司与供应商发生采购关系时，外部 Agent 始终是供应商。我们把内部 Agent 和外部 Agent 分开存，后续做往来对账时只需要按外部 Agent 过滤，不会出现一个人名挡住一整条链的情况。

时间边界：必须区分“业务发生时间”和“系统记录时间”。入库单可能月底补录，发票可能隔月才到，如果统一用创建时间，成本计算就会错位。REA 里我们强制同时存 occurred_at（业务发生时间）和 recorded_at（记录时间），所有余额计算一律以 occurred_at 为准。

2.3 我总结的“双看”检查口诀

我们代码评审时有一条不成文的规矩：每个新增的 Event 都要能回答三个问题——什么资源变了？谁授权或参与的？什么时候发生的？如果答不上来，这个事件就退回重设计。这个方法帮助很大，团队里新来的开发照着这三个问题就能自己判断。

另外还有一个“双看”技巧：从业务端看，事情是不是真的发生了；从数据端看，资源的余额会不会因为这个事件而改变。两个都选“是”，才是合格的经济事件。如果只有业务端为真，那可能只是流程动作；如果只有数据端为真，那可能只是计算逻辑。我们在项目里用这个口诀筛掉过不少想多建模的冲动。

3. 用 REA 落地记账核心

3.1 表结构到底怎么设计

理论模型最终要落到表上。我们的最终方案不是一张大表，而是四张核心表：参与者表（agent）、资源表（economic_resource）、事件表（economic_event）、事件链接表（event_link）。前两张可以理解为维度，后两张共同构成事实。

下面是一个简化但可跑通的建表结构，实际项目中会加租户、软删除、审计字段，这里为了讲清楚主干就省略了：

CREATE TABLE economic_event ( id BIGINT PRIMARY KEY, event_type VARCHAR(64) NOT NULL, -- purchase_receipt / sale_issue / payment / receipt / adjustment occurred_at DATETIME NOT NULL, -- 业务实际发生时间 recorded_at DATETIME NOT NULL, -- 系统记录时间 internal_agent_id BIGINT NOT NULL, -- 内部参与者（采购员/仓管员） external_agent_id BIGINT, -- 外部参与者（供应商/客户） business_ref_no VARCHAR(64), -- 上游业务单号，仅作引用，不作为核心关联 UNIQUE KEY uk_business_ref (business_ref_no) ); CREATE TABLE economic_resource ( id BIGINT PRIMARY KEY, resource_type VARCHAR(64) NOT NULL, -- inventory / cash / receivable / payable sku_id BIGINT, -- 实物资源关联商品 warehouse_id BIGINT, -- 实物资源关联仓库 currency CHAR(3) -- 货币资源 ); CREATE TABLE event_link ( id BIGINT PRIMARY KEY, link_type VARCHAR(32) NOT NULL, -- increment / decrement / authorization / duality event_id BIGINT NOT NULL, resource_id BIGINT, agent_id BIGINT, linked_event_id BIGINT, -- 用于 duality 配对 quantity DECIMAL(20,4), amount DECIMAL(20,2), UNIQUE KEY uk_event_link (link_type, event_id, resource_id, linked_event_id) );

这套结构里，event_link是灵魂。它把事件和资源、事件和事件之间的关系全部显式化。查询“某批咖啡豆的完整履历”时，只需要从 resource 出发，找到所有 link_type = 'increment' 或 'decrement' 的链接，再返回去 join event 表，整条链路就出来了。

3.2 用事件链接保证“账对得上”

账目对不上的根源，往往是两个模块各自记了一笔，互相之间没有任何约束。REA 的落地方案用 event_link 把这种约束变成数据库层面的强制关系。

我们的做法是：采购入库事件和付款事件之间，插入一条 link_type = 'duality' 的关系。只要一笔入库没有对应的付款事件，系统就能在应付账龄报表里标成“未配对”。同样，销售出库和客户回款也建立 duality 链接。对账不再是月底人工勾稽，而是每天运行一次配对检查，把“孤事件”直接列出来。

这里要说明一点：配对并不总是端到端的一一对应。一笔采购分三次付款很常见，一笔销售可能对应多笔回款。所以我们在 event_link 里没有做成“1 对 1 唯一键”，而是允许一条入库事件对应多条付款事件；配对状态机分三档：未配对、部分配对、完全配对。每次插入付款事件时，用事务同时检查该事件对偶链接的累计金额是否达到原采购金额，达到就把状态置为完全配对。

为了防重，每个从旧系统或上游同步过来的事件都会带上业务流水号，business_ref_no建了唯一约束。同步引擎重试一百次，也不会插入两条相同的事件。这个细节看似简单，但线上真出现过一次重复死锁，排查到最后就是唯一约束兜住了底。

3.3 渐进式替换：别想着一夜之间推倒重来

如果一开始就决定把核心账务全部换成 REA，我猜我们项目大概率会失败。业务部门天天要用系统，你突然把单据都换掉，谁都接受不了。我们实际采用了“影子账本”策略。

新账本并不直接替代旧系统，而是每天从旧系统的日志事件里重建一份 REA 事件流，然后独立计算库存余额、应收余额、应付余额。每天早上跑一次对账脚本，把 REA 算出来的余额和旧系统报表做比对。刚开始差得离谱，因为旧系统里不少历史库存是负的；但运行一周后，差异逐渐收敛。我们连续两个周一对账全部一致之后，才把库存查询和往来对账的流量切到新模型上。

流量切换也不是一把全切。我们只先把“库存余额查询”和“应收账龄表”两个耗时的报表迁移到 REA 投影表，业务操作的单据界面仍然保留，让前端感知不到底层变了。这种渐进式方案被同一个业务方连续否了两版流程设计之后，最终顺利通过了。那句话怎么说来着？大规模重构，活下来才是第一目的。

4. 迁移老系统时踩过的三个坑

4.1 坑一：团队拿“单据思维”硬套 REA

第一个坑来得比想象中早。第一轮模型评审时，开发交上来的 E-R 图里居然还有“采购单表”“销售单表”“付款单表”，只是在边上加了一个 Event 标签。说白了，大家还是在用单据思维理解 REA。

问题出在哪？单据是流程产物，它有状态、能修改、可以被作废；而 REA 里的事件是不可变的经济事实。把两者混在一起，事件表里就会出现“草稿”“已提交”“已审核”这类状态字段，那跟原来的订单流有什么区别？

我们花了一个下午做了裁决：把事件表里的状态字段全部去掉，事件只有“已发生”这一个事实；单据继续存在于独立的流程表中，作为用户操作界面和审计档案，但核心余额计算必须走事件流。订单状态机还是一张普通表，但它不再参与账务计算。团队后来适应了这种分离，开发效率反而提上来了，因为每个人都很清楚“这个字段到底该放哪”。

4.2 坑二：资源归集和事件归属的边界纠缠

第二个坑是线上真实事故引起的。销售退货发生时，库存会增加，这个增量事件本来应该通过 duality 链接到原销售出库事件。但初版设计里，我们的实现人员为了查询方便，直接在 event_link 表上额外挂了一个“原订单号”字段，然后报表按订单号分组统计。

听起来没毛病，但实际业务里有合并订单、拆单发货、部分退货。一旦同一个销售事件被两笔退单挂靠，订单号分组统计就会把库存增量重复计入。我们当时排查了很久，最后发现根因是：用订单号作为事件归属关系，等于把流程标识和事实关系混在一起。退货库存增量属于原销售事件，而不是属于原订单；业务上“这张单退了货”是流程需求，数据上“这次增量抵消了哪次出库”是事实需求。

后来的方案很朴素：退货事件与原销售事件之间建立 duality 链接，不打任何订单号；报表需要订单维度时再去 join 流程表，而不是在事件表里提前存。这个坑教会我一件事：建模时想要报表方便，反而会破坏模型纯度；模型纯了，报表路径其实更清晰。

4.3 坑三：历史数据“一次性清洗”的陷阱

很多重构项目死在历史数据迁移这一步。我们第一批次想当然地以为，把过去三年的入库单、出库单、付款单一次性转成事件流就行了。结果工单跑了一整夜，第二天早上报错数量高得吓人：负数库存、重复发票、金额和数量对不上的历史单满天飞。

那两天团队差点吵散。后来我们换了策略，做了一次很关键的决定：已结束的会计期不迁移，只从迁移启动日重建期初余额。具体操作是，选一个月初作为迁移基准日，把旧系统当日的库存数量、加权平均成本、应收余额、应付余额作为 REA 的期初资源快照写入资源表；从基准日之后业务事件才陆续进入事件流。

这样做的代价是历史查询不能用 REA 直接穿透，但换来了巨大的可控制性。对账逻辑变得非常简单：期初余额加上事件流增减，理应等于当日余额。一旦不等，就一定是最近两天的事件有问题，无限缩小了排查范围。审计那边也认可这个方案，因为期初快照有据可查，迁移窗口内事件链完整，没有强行篡改历史的痕迹。

5. 后续扩展：REA 与事件溯源、多维分析

5.1 REA 天然接近事件溯源，顺水推舟

重构进行到后半程，我们发现 REA 和事件溯源（Event Sourcing）几乎是无缝衔接的。REA 的事件表本来就是不可变的事实流，Event Sourcing 要求的一切——只追加、不更新、可回放——它在设计上都已经满足。

我们最后做了一次升级：把 economic_event 表直接作为事件存储，库存余额、应收余额、应付余额全部变成投影表。每当新事件写入，系统通过消息队列触发投影更新；如果某个投影因为 bug 被污染，只要清空它，从事件流重新聚合一遍就能恢复。这在旧系统里是不可想象的，为了修一个成本模块的错误，我们以前要写好几十条 SQL 修补脚本。

回放能力带来的还有成本重算的便利。比如公司突然要求从本季度开始改用先进先出法，旧系统只能在存量数据里打补丁。现在只要改一个投影计算器，从事件流头部重新计算目标时间段的余额就行。这个灵活性，是我们在项目计划阶段完全没预料到的红利。

5.2 用 REA 看多维分析

老系统要出一张“按商品、按仓库、按日期的库存流水”报表，通常要 join 四五张表，存储过程写了几百行。REA 模型下，这个问题简单到可以用一条 SQL 说明思路：

SELECT r.sku_id, r.warehouse_id, COALESCE(SUM(CASE WHEN l.link_type = 'increment' THEN l.quantity ELSE 0 END), 0) - COALESCE(SUM(CASE WHEN l.link_type = 'decrement' THEN l.quantity ELSE 0 END), 0) AS balance_qty FROM economic_event e JOIN event_link l ON e.id = l.event_id JOIN economic_resource r ON l.resource_id = r.id WHERE e.occurred_at <= :end_time AND r.resource_type = 'inventory' GROUP BY r.sku_id, r.warehouse_id;

这个查询能跑通的根基是事件不可变和事件链接规整。只要事件发生时间不撒谎，任意时间点的库存余额都能通过回放得到。我们后来把分析报表全部切成这种“事件流聚合”模式，不再依赖业务表里那些时对时错的冗余字段。

有一点需要提醒：数量余额和金额余额要分开处理。事件链接表里同时有 quantity 和 amount，但成本计算方法（移动加权平均、先进先出）是在投影层实现的，不应该污染事件层的纯度。事件层只记录“发生了什么”，成本是如何计算的，那是核算逻辑自己的事。

5.3 我的真实感受：陡峭但值得

如果现在有人问我，REA 值得不值得学、值不值得用，我会说分场景。一个几千单量的小型进销存，传统 CRUD 加几张统计表完全能跑，没必要上 REA。但只要是账务要算清、历史要能查、角色之间经常扯皮的系统，REA 带来的长期价值是真实存在的。

最大的收获不是模型本身，而是它逼着团队在写代码之前先想清楚“业务事实到底是什么”。我们项目里很多以前吵不清楚的需求，在“这个事件改变哪个资源”的追问下迅速显形。当然代价也有，团队里必须有人真正理解经济对偶，否则很容易把 REA 建模成一种另类的订单流。最后分享一个我们内部的小习惯：每次有同事提出想往事件表里加一个“状态”字段，我们就把它当成一次模型预警信号，停下来重新对一遍业务事实。这套做法已经帮我们躲过了至少三次设计漂移。