REA 事件建模：用事件替代余额，构建可追溯业务数据模型

在系统设计领域，“REA”第一次出现时，很多人会以为它是个工具名、某个框架缩写，甚至是一个人名，没什么感觉。但如果你的工作是和数据模型、财务数字化、供应链系统打交道，大概率迟早会撞上它，这就是 Resource-Event-Agent——资源、事件、代理，一套从会计信息系统研究里走出来的业务建模方法。我为什么愿意花大篇幅写它？因为它改变的不只是表结构，而是你判断“什么是业务事实”的底层习惯。这篇文章会用销售和采购案例，把它拆成可以直接抄的模型、建表思路和迁移方法，也把最容易踩的坑一并说清楚。适合后端架构、数据产品、财务数字化团队，以及所有正在被“库存总对不上”“账实不符”折磨的开发同学。

1. 把 REA 放到实际业务场景里理解

1.1 传统“余额表”模型到底哪里别扭

先看一个很常见的系统设计：库存表里有一列“当前结存”，每次出入库都直接对这个字段做加减。设计简单是简单，但问题也出在这里——你最终看到的只是一个数字，而不是“为什么变成这个数字”。

举个例子：月底盘点发现少了 5 件，仓库管理员直接做了一个“盘亏单”，系统把库存从 100 改成 95。看上去很合理，但审计时麻烦就来了：这 5 件到底是入库错了、被偷了、还是退换货没录入？如果只有余额表，你永远只能看到“它少了”，却无法回答“它怎么少的”。

REA 模型不这么干。它主张把“业务动作”当作最原始的事实，也就是事件。库存结存是多少，只是把这个时间段内所有“入库事件”和“出库事件”做汇总的结果。余额是推导出来的，不是直接存出来的。

这样做最大的受益点有三个：每一笔变动都能追溯；出现了错误只需要补录“反向事件”，而不是改数字；不同部门只要依据同一套事件表，口径自然就一致了。

1.2 REA 不是某一个软件，而是一套观察业务的方式

REA 的全称是 Resource-Event-Agent，也就是资源、事件、代理，后来又补充上了事件之间的“双重性”等关联规则。说直白一点，它要求你在设计系统时把业务拆成三件套来观察。

• 资源（Resource）：企业里被管理、被交换、被消耗的东西，比如现金、库存商品、原材料、工时、服务。
• 事件（Event）：真正改变了资源状态的动作，比如“出库”“收款”“收货”“发工资”。
• 代理（Agent）：参与这个事件的人、部门或组织，比如客户、供应商、采购员、仓库管理员。

看到这里你可能会想：这不就是把业务流程画成流程图吗？差不多，但关键区别在于，REA 强调只有“真实发生且改变资源状态”的动作才能叫事件，像“审核通过”“生成了订单”这类管理动作不算经济事件，它更像最终状态的一个标识。用这套思路建模后，你会发现系统里不再有一个个“孤岛数据”，而是一条完整的事件链。

2. REA 的核心概念：资源、事件、代理与关系

2.1 资源（Resource）不只包含存货和现金

如果把 REA 拆字来看，“资源”是最容易被理解成“库存”的概念。实际上，它的范围比会计科目上的资产还要宽。

以一家做软件开发的公司为例。现金是资源，服务器是资源，程序员提供的一个小时工时也是资源，客户买到的使用许可同样是资源。只有符合两个条件的，才值得被建模成资源：第一，它能在事件中被交换、转换或消耗；第二，它的来龙去脉需要被追踪。

有必要注意一个细节：资源也不一定都是实物。现代业务里，碳排放指标、会员积分、虚拟资产的转让，都可以建模成资源。它的本质是“经济价值的载体”，而不是某个数据库表。

2.2 事件（Event）是唯一可以直接修改资源状态的对象

事件在 REA 中处于核心地位，它定义了“某个资源在某个时间点发生了什么变化”。事件必须包含三个信息：发生在哪个资源上、方向是流入还是流出、发生在什么时间。

举个例子，仓库收到供应商送来的 100 个物料，这不是一个“入库单”状态，而是一个“物料入库”事件，对应资源“物料库存”，方向流入，事件发生时间是验收完成的时刻。再往后，车间领走 30 个物料生产，订单完工后又产生一个“产成品入库”事件。

为什么要把事件单拎出来说？因为我见过太多团队把“单据状态”当事件来用。单据状态是“已审核”“待付款”，它只代表流程走到哪一步，不代表资源真实发生变化。如果系统里只有“订单状态”没有“资源变动记录”，那么月底的财务对账就变成了一场灾难。

2.3 代理（Agent）决定了权责归属

代理解决的是“谁干的、谁该负责”的问题。内部代理是公司里的员工、部门，外部代理是客户、供应商、物流公司，甚至可以是自动化规则授权的系统机器人。

事件是守恒的，但代理往往要成对出现。比如“客户付款”这个事件，至少有两个代理：付款的客户和收款的出纳。如果把代理也数字化，还应该区分出“经办人”和“负责人”，这样后续做绩效分析、风控、权限隔离时才有依据。

2.4 三种核心关系加上双重性，模型才闭合

光有资源、事件、代理三个概念还不够，还要描述它们之间的连接。

• 资源流（Stock-flow）：事件会改变资源库存，方向可能是流入、流出或转换。例如“入库”事件对应资源流入，“报废出库”事件对应资源流出。
• 参与（Participation）：代理和事件之间多对多的关系，表达“谁参与了这个事件”。
• 触发（Trigger）：事件之间有先后顺序，例如“客户下单”触发“仓库发货”，仓库发货触发“财务收款”。

在此基础上还有一个至关重要的规则——双重性（Duality）。简单说，一个业务过程通常包含两个配对的事件：一个事件消耗或流出资源，另一个事件获得或流入资源。比如“发货”是一个资源流出事件，对应的“收款”是一个资源流入事件；“采购入库”是资源流入事件，对应的“对外付款”是资源流出事件。

很多业务对不上账，就是因为拆分时只记录了“一半事件”，比如只记发货不记应收款，只记采购不记应付款。双重性规则帮你自动补齐另一半。

2.5 用采购场景看最小模型长什么样

把上面的概念落到一张表里，会更直观。

注意最后一个退货事件只是进行了反向的资源流，没有修改前一笔入库事件，而是新增一个“退货出库”事件。这种“只追加、不修改”的做法，就是 REA 模型在审计性上最大的优势。

3. 用“销售发货”完整梳理一套 REA 数据模型

3.1 识别事件和资源流的顺序

我建议建模时不要一上来就打开数据库画表，先按下面顺序走一遍：

1. 从业务流程清单里筛选动作，例如“接收订单”“发货”“收款”“退货”“冲红”。
2. 判断哪些动作真正改变了资源状态，只有这些能成为事件。
3. 为每个事件找到它所影响的资源，并标清流入还是流出。
4. 找出参与事件的内部代理和外部代理。
5. 将单个事件按双重性配对，形成完整循环。

拿销售来说，我们可以得到以下事件链：客户提交订单（触发事件）— 仓库发货（资源流出：库存商品）— 财务确认应收款（这里也可以看作应收账款资源流入）— 客户付款（资源流入：银行存款）— 如果发生退货，则原路反向记录。

链条一旦建立，后续查询就很简单了：想知道这个月所有已发货但未付款的订单，不需要维护状态位，直接通过“发货事件”和“收款事件”做比对就能找到。

3.2 数据库关系表设计：资源、事件、代理怎么落地

REA 模型落地到关系数据库，至少需要四类表，核心是事件表和关联表。

-- 资源表 CREATE TABLE resource_tb ( resource_id BIGINT PRIMARY KEY, resource_code VARCHAR(32) UNIQUE, resource_name VARCHAR(128), resource_type VARCHAR(32) -- INVENTORY / CASH / SERVICE / POINT ); -- 代理表 CREATE TABLE agent_tb ( agent_id BIGINT PRIMARY KEY, agent_type VARCHAR(16), -- INTERNAL / EXTERNAL agent_name VARCHAR(128) ); -- 经济事件表 CREATE TABLE economic_event ( event_id BIGINT PRIMARY KEY, event_type VARCHAR(32), -- PURCHASE_IN / SALES_OUT / PAYMENT agent_id BIGINT NOT NULL REFERENCES agent_tb(agent_id), resource_id BIGINT NOT NULL REFERENCES resource_tb(resource_id), direction VARCHAR(8) NOT NULL, -- IN / OUT quantity NUMERIC(18,4) NOT NULL, occur_time TIMESTAMP NOT NULL );

这里我故意只写了一层简化结构。如果要在企业里真正用起来，还会加一张“事件参与明细表”来支持一事件多代理，以及“事件触发关系表”来记录先后关系。但你要记住的核心原则是：经济事件表是事实表，资源表和代理表是维度表，余额永远不单独存在事实表里最安全。

3.3 从事件推导余额，而不是直接保存余额

如果我们不做“余额”字段，业务系统想看当前库存怎么办？答案是用 SQL 实时计算。

SELECT r.resource_code, r.resource_name, COALESCE(SUM(CASE WHEN e.direction = 'IN' THEN e.quantity ELSE -e.quantity END), 0) AS current_balance FROM resource_tb r LEFT JOIN economic_event e ON e.resource_id = r.resource_id WHERE r.resource_id = :target_id AND e.occur_time <= :query_time GROUP BY r.resource_code, r.resource_name;

这段 SQL 会返回截至某个时间点的资源余额。生产系统里如果事件量很大，直接全表聚合会有压力，但解决方案不是回到余额表，而是增加“余额快照表”并在每小时或每日定时构建快照。快照只是缓存，事件表依然是唯一权威事实，这样既保证性能，又不牺牲可追溯性。

3.4 这种建模的优势和成本

优势比较明显：审计链路完整，不需要再对“期末余额—期初余额—本期发生”去推导；业务扩展代价小，新增一种业务场景时，只需要新增事件类型和资源类型，而不是到处加字段；跨部门口径统一，不做“两套账”的直接原因就是底层事实一致。

代价也要承认。模型较抽象，业务方要理解“事件”和“单据”的关系需要时间；查询建模比直接查“余额表”复杂；初次建模时对领域业务理解要求高，找错事件会导致后续全盘返工。所以我一般建议：先拿一个核心流程例如销售或库存做试点，不要一开始就全面推翻旧系统。

4. 实操：从事件识别到代码落地

4.1 建立“事件只追加，不修改”的纪律

REA 模型要生效，第一纪律就是不要修改历史事件。发现记录错了，不是去改那条发生时间，而是补一条“更正事件”或“反向事件”。

原因听起来很玄，但实际操作中很现实。一旦允许修改事件表，审计进行到一半，原值变了，余额和别人系统的余额就对不上了。团队内部经常发生“你改了，我不知道，月底对账崩掉”的悲剧。

我建议在建表时就留好这几个字段：event_id、original_event_id、event_status、cancel_reason。业务上的“红冲”和“退货”都通过新增事件来体现，并记录它们引用哪个原始事件。时间久了，你会发现自己对数据有了很强的安全感。

4.2 用 Python 写一个最小的事件余额计算模型

如果不想一开始就上数据库，可以用简单 Python 类先验证业务规则。这里给一个最小实现，便于在需求阶段和业务方对齐。

from dataclasses import dataclass from datetime import datetime from typing import Optional @dataclass class EconomicEvent: resource_id: str direction: str # "IN" 表示资源流入， "OUT" 表示资源流出 quantity: float occur_time: datetime def compute_balance( events: list[EconomicEvent], resource_id: str, as_of: Optional[datetime] = None, ) -> float: balance = 0.0 for event in events: if event.resource_id != resource_id: continue if as_of and event.occur_time > as_of: continue if event.direction == "IN": balance += event.quantity elif event.direction == "OUT": balance -= event.quantity else: raise ValueError("direction 只能为 IN 或 OUT") return balance events = [ EconomicEvent("CASH", "IN", 10000, datetime(2025, 1, 1, 10, 0)), EconomicEvent("CASH", "OUT", 3000, datetime(2025, 1, 2, 12, 0)), ] print(compute_balance(events, "CASH"))

这个代码很基础，但已经表达出 REA 最有价值的含义：余额不是实体，而是函数计算出来的视图。到这里，你会发现它和“事件溯源”架构在思想上几乎是一家人。

4.3 历史系统迁移到事件模型的五步改造

从传统余额表改造成 REA 事件模型，一般分五步走：

1. 盘点现状：整理现有系统里所有状态字段，例如库存结存、银行存款余额、应收款余额。
2. 反推事件：针对每个余额字段，梳理历史上是什么动作让它发生变化，把它们定义为事件。
3. 清洗历史：把旧系统的流水明细按新事件结构转换。注意，旧系统里可能只有结果没有流水，这类缺口就要用“期初事件”一次性补齐，也就是通过一个“初始化事件”把期初余额写入事件表。
4. 并行试跑：新旧系统并行运行一个月，每日用自动对账任务比较两边余额，差异大于零就是补录逻辑有遗漏。
5. 切换与封存：新系统切换后，旧系统只读保留，不再允许手工改数。

我见过很多团队把前三步压缩成“几天搞定”，结果旧系统里大量历史调整记录只有日志没有数据，最后还得靠业务人员回忆补录。这块真的急不得。

4.4 性能与并发控制的注意点

事件表会随着业务增长越来越庞大，不处理的后果就是查询越来越慢。常用的缓解手段有几个：一是按月分表，查询时先定位月份再汇总；二是定期构建“余额快照”，只保留最近一月的实时事件明细，更早的时间点直接读快照；三是引入消息队列异步汇总，事件写入主库后，再异步更新聚合表。

并发控制上，事件表比余额表好做得多。因为事件往往是追加写，主键明确，冲突天然少。真正要关注的是业务幂等性，同一个动作重复提交时不能生成两条事件，所以需要在事件表加业务流水号唯一索引，而不是只依赖自增主键。

5. 常见问题与排查技巧实录

5.1 订单、报价单到底是不是事件？

不是。订单是双方的一个承诺，它会在未来触发一系列经济事件，但本身没有真正改变经济资源。我常用的判断方法是：把这张单删掉，资源状态会不会变？如果不会变，它就不该作为事件进入 REA 模型。订单状态可以作为业务流程信息单独维护，再通过触发关系连接到发货事件。

5.2 一笔资金被记在多个资源里，怎么排查？

这类问题通常出现在“同一笔金额，既当成现金增加，又当成销售收入确认”的情况。REA 里排除靠两条原则：不同的资源要对应不同的资源类型，同一笔资金流只能在一个事件中被记录；双重性要求事件成对出现，但资源类型不能重复。排查时先按事件维度汇总金额，再和原业务凭证比对，只要某个资源同时出现在多个互相矛盾的事件里，大概率就是建模阶段就拆错了。

5.3 月度结账和 REA 事件模型怎么兼容？

传统月度结账关心的是“这个月发生额是多少”。REA 里只需要在查询时加时间过滤条件，就能得到多种口径的本期发生额。但真正要小心的是跨期调整，比如 12 月补录了 10 月的退货，如果直接删掉原事件会让历史月度快照变形。正确做法是新增调整事件并标记调整期间，这样 10 月原快照不变，12 月则同时体现出调整影响。

5.4 事件表数据膨胀后，性能优化怎么做？

我整理了一个排序方案，按性价比从高到低：

• 资产：对事件表按“资源类型+发生时间”建立复合索引，日常查询都能走索引。
• 第二步：把早期明细迁移到冷存储，只保留汇总快照。
• 第三步：增加应用层缓存，对热点资源如现金账户的当日余额做短期缓存，缓存失效再重新聚合。
• 最后才考虑上分布式数据库，别一上来就换底座，很多时候索引和归档就把问题解决了。

最后分享一点个人体会

我在之前做供应链重构时，团队最难的其实不是建表，而是说服大家放弃“直接改余额”的习惯。仓库同事习惯了改结存数字，财务同事习惯了月底对科目，一旦改成事件模式，大家刚开始都觉得麻烦。但撑过了并行期之后，效果立刻显现：库存差异不再需要头痛医头脚痛医脚，任何一笔差异都能顺着事件找到原始业务；财务也不用半夜等人补凭证，系统自己就能产出对账结果。

如果你只听理论，REA 确实像学术概念。但一旦把它当作“用事件替代余额”的工程原则来落地，你会发现它和一流的审计系统、账务系统背后的设计思想其实是同一条路。我建议一切刚开始做业务中台设计的人，先在采购或库存这个核心流程上小范围试点，跑通后再逐步铺开，这条路虽然要先绕一点远路，后面却会省下大量处理数据不一致的时间。