REA模型：以资源-事件-代理人重构企业业务数据建模

标题写成 rea，不是笔误，也不是某个开源库的名字缩写，而是一套在会计信息系统和企业建模领域存在了几十年的范式：Resource–Event–Agent，资源–事件–代理人。我第一次重新认真研究它，是被一个反常识的问题逼的：为什么我们的订单表里，非得同时存客户ID、商品ID、金额字段，然后让库存表和一张“财务凭证”表硬生生绑在一起？业务上一个“卖出两台服务器”的动作，被拆得到处都是。想回答“这台服务器是从哪个仓库出的、经由哪位销售、对应哪笔款项、最终回款没有”，得先写半个小时的SQL。

这套模型刚好回答这类问题。如果你正在做订单、库存、财务、审计类系统的建模，或者你在数据平台里做面向业务的可追溯模型，又或者你只是被“业务语言”和“财务语言”对不上这件事折磨过，REA都值得你花一个下午重新认识一下。它不是银弹，但确实能帮你把数据库从“一堆科目表”变成“一组业务事实”。

1. 为什么我放弃了纯借贷记账模型，改从事件视角建表

1.1 传统总账结构到底哪里不对劲

早期接手的某个订单和库存系统，表结构明显是按“会计科目”的思路设计的。订单主表里有 debit_account、credit_account 字段，子表也带着方向标识，库存表里甚至还存了 amount 字段。业务是能跑的，数据也能对上，但每次想从业务角度分析问题就非常痛苦。

举一个最简单的例子：卖两台服务器给客户A。在传统结构里，这一笔动作至少要拆成订单表、订单明细表、库存台账表、财务凭证表四处落库存。订单只知道客户，库存只知道仓库，财务凭证只知道科目和金额。业务上明明是同一件事，但任何一张表都无法独立描述“谁在什么时间把什么货从哪个仓库给出去了”。

后来有人问我：这个客户这个月退货三次，分别是从哪些仓库出的货？传统模型下的回答方式是把订单、库存流水、财务凭证按科目 join 在一起，然后再祈祷没有人在“退货”时写了“其他入库”这种口径不一的凭证。如果已经发生了这种情况，那就不是写SQL的问题了，是模型层面根本没有“业务事实”这个概念的必然结果。

1.2 REA 是怎么切入这个问题的

REA 的核心主张非常简洁：把企业描述成一系列经济事件，每个事件会改变经济资源的控制关系，并牵涉到若干代理人。换句话说，建模重点不再是“账怎么记”，而是“发生了什么”。

资源很好理解：库存商品、现金、固定资产、应收账款这些可被控制和交换的对象，都属于经济资源。代理人更好理解：客户、供应商、销售员、仓管员、财务经办人，都是参与业务的人或组织。事件是连接两者的枢纽：销售、采购、收款、付款、退货、领料、入库，这些动词统统可以建模为经济事件。

这样一来，传统借贷记账模型并不是被推翻了，而是被降级了。借贷仍然是会计语言，但如果系统层只有这种语言，业务侧、管理侧、风控侧就无法直接消费数据。REA 的做法是在账务层之上建立一个业务事实层，让每个业务动作成为一个中心节点，资源和代理人像卫星一样围绕它转。

这套思想最早流行于会计信息系统领域，后来在企业架构、数据中台、ERP 设计中被广泛借鉴。现在我在设计新系统时，已经很少先画“订单表怎么拆”了，而是先问一句：这里有哪些事件，它们改变了哪些资源，谁参与了。

2. REA 的三类核心对象与三条关系链

2.1 资源、事件、代理人各管什么

REA 把业务世界抽象成三种高层对象，这比直接画二十张业务表要清晰得多。

我第一次用这套分类去审视旧系统，最大的收获是发现自己以前太喜欢用“名词表”建模了。订单、商品、客户，全都是名词，数据库建出来之后感觉很规整，但一旦要回答“这笔订单是哪个销售什么时候卖出去的货”这种带动词的问题，就得跨三张表去猜。

其实业务系统最核心的信息藏在动词里。销售、收款、出库、入库，这些动作才真正反映了业务状态的变化。REA 逼你先列出动词，再围绕动词设计名词表，顺序一变，整个模型就活了。

2.2 三条关系链：资源事件、问责、经济链

REA 不像普通 ER 模型那样只关心“谁跟谁有关系”，它隐含了三类必须明确的关系。

第一条是资源-事件关系，也叫存量-流量关系。每个经济事件至少会让一种资源流入、一种资源流出。例如销售事件让“库存商品”流出，同时让“应收账款”这种权利性资源流入。收款事件则让“现金”流入、“应收账款”流出。这种关系可以自动形成存量-流量视图，为实时库存余额和应收余额提供事实基础。

第二条是事件-代理人关系，也叫问责关系。每个经济事件至少要关联两个角色：内部代理人，比如销售员、仓管员、财务经办人；外部代理人，比如客户或供应商。这样设计的目的是事后审计时可以明确知道“谁经办、对谁经办”，同时为职责分离提供数据支撑。

第三条是事件-事件关系，也叫经济链。事件之间不是孤立的，销售事件后面会跟着收款事件，采购事件后面会跟着付款事件。这些事件通过经济链连接起来，就形成了一条完整的业务证据链。比如“销售→收款”、“采购→付款”、“领料→生产→入库”。经济链又可以分为交换和转换两类：交换是双方互相转移资源，转换是内部把一种资源变成另一种资源。

2.3 为什么“事件”这个维度总是被忽略

很多后端开发拿到业务需求时，第一反应是“建订单表、建商品表、建客户表”，这些名词对象看起来稳定，于是被优先落库。事件却经常被处理成状态字段，例如订单表里的 status 从 pending 变成 paid。这种做法把“过程”折叠成了“状态”，历史细节就消失了。

REA 的视角是：状态只是某个时点的快照，事件才是事实本身。订单状态从 pending 变成 paid，背后至少应该有一条“收款事件”和一条“销售事件”之间的经济链。如果模型里没有事件表，那么所有状态变更都会变成覆写式更新，分析人员只能拿到当前状况，拿不到变化路径。

所以我现在设计表结构时，会刻意要求自己回答一个问题：这个业务动作能不能在数据库里找到对应的一行记录？如果找不到，说明它被隐藏在了某个 update 语句里，这通常就是后续扯皮与返工的开始。

3. 一个从订单到回款的完整 ER 模型重构实例

3.1 原始表结构长什么样

假设我们要支持一个简单的销售流程：客户下单 → 仓库发货 → 财务确认回款。传统表结构大概长这样：

CREATE TABLE orders ( id INT PRIMARY KEY, customer_id INT, total_amount DECIMAL(12,2), status VARCHAR(32), debit_account VARCHAR(64), credit_account VARCHAR(64) ); CREATE TABLE order_items ( id INT PRIMARY KEY, order_id INT, sku_id INT, quantity INT, unit_price DECIMAL(12,2) ); CREATE TABLE sku_inventory ( sku_id INT PRIMARY KEY, warehouse_id INT, quantity INT, amount DECIMAL(12,2) );

这个模型的问题有三处。第一，订单表混入了财务科目字段，业务和账务耦合在一起。第二，库存表直接存金额，导致每次库存移动都要同步更新金额，口径很容易不一致。第三，“回款”这个动作没有独立的表，只有一个 status 字段，历史完全不可追溯。假如财务在系统里改过一次状态，后来数据对不上，谁也说不清问题出在哪一步。

3.2 按 REA 思路重构核心表

我落地时没有一步到位用完整的 REA 本体，而是先做一个简化版，保留最核心的五张表加三张关联表。

CREATE TABLE agents ( agent_id BIGINT PRIMARY KEY AUTO_INCREMENT, agent_type VARCHAR(16) NOT NULL, -- INTERNAL / EXTERNAL agent_code VARCHAR(64), display_name VARCHAR(128) ); CREATE TABLE economic_resources ( resource_id BIGINT PRIMARY KEY AUTO_INCREMENT, resource_type VARCHAR(32) NOT NULL, -- INVENTORY / CASH / RECEIVABLE / PAYABLE resource_code VARCHAR(64), resource_name VARCHAR(128) ); CREATE TABLE economic_events ( event_id BIGINT PRIMARY KEY AUTO_INCREMENT, event_type VARCHAR(32) NOT NULL, -- SALE / PAYMENT / RETURN occurred_at DATETIME NOT NULL, recorded_at DATETIME NOT NULL, reference_no VARCHAR(64) ); CREATE TABLE event_resource_links ( link_id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, direction VARCHAR(8) NOT NULL, -- IN / OUT quantity DECIMAL(18,4) NOT NULL, amount DECIMAL(12,2) NOT NULL DEFAULT 0 ); CREATE TABLE event_agent_links ( link_id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id BIGINT NOT NULL, internal_agent_id BIGINT NOT NULL, external_agent_id BIGINT, role VARCHAR(32) ); CREATE TABLE event_event_links ( link_id BIGINT PRIMARY KEY AUTO_INCREMENT, prev_event_id BIGINT NOT NULL, next_event_id BIGINT NOT NULL, link_type VARCHAR(32) NOT NULL -- EXCHANGE / CONVERSION );

有人会问：为什么不用一张大宽表把所有事件字段都塞进去？原因有两个。一是不同事件的属性差异很大，销售事件有成交价，收款事件有付款渠道，退货事件有质检结果，塞在一张大表里会导致大量空字段。二是 REA 强调的是关联关系，不是事件类型本身，分开表达会让“某个事件改变哪些资源、涉及哪些人”这个问题变得很直接。

3.3 同一笔业务在 REA 里怎么落数

还是“把2台服务器卖给客户A，单价1万，总价2万，约定30日内回款”这个例子。业务侧的动作被拆成两个事件。

第一个事件是销售事件。库存服务器减少2件，对应 event_resource_links 中一条 direction 为 OUT、quantity 为2、amount 为20000 的记录。同时应收账款这种资源增加2万，对应一条 direction 为 IN 的记录。参与人是销售员B和客户A，落到 event_agent_links。

第二个事件是收款事件。30天后客户A转账2万到公司账户，财务C确认到账。此时现金资源增加2万，应收账款减少2万。参与人是财务C和客户A。最后在 event_event_links 里插入一条从销售事件指向收款事件的 EXCHANGE 链接。

这样设计后，你会发现一件很微妙的事：应收账款并没有像传统总账那样做借贷分录，而是被建模成一种“事件产生的权利”。当事件链完成，销售加收款的完整循环走完，应收账款归零，资源状态依然保持平衡。

3.4 一条 SQL 拉通完整的业务证据链

查询“某个客户在某段时间内参与过的所有事件及其资源流动和责任人”，可以直接从事件主体出发 join 三张关联表：

SELECT e.event_id, e.event_type, e.occurred_at, r.resource_code, r.resource_name, el.direction, el.quantity, el.amount, ia.display_name AS responsible_person, ea.display_name AS counterparty FROM economic_events e JOIN event_resource_links el ON el.event_id = e.event_id JOIN economic_resources r ON r.resource_id = el.resource_id JOIN event_agent_links eal ON eal.event_id = e.event_id LEFT JOIN agents ia ON ia.agent_id = eal.internal_agent_id LEFT JOIN agents ea ON ea.agent_id = eal.external_agent_id WHERE eal.external_agent_id = :customerId AND e.occurred_at >= '2025-01-01' ORDER BY e.occurred_at, e.event_id;

同一事件如果关联了多种资源，查询结果里就会出现多行，每行对应一种资源的流入或流出。一眼就能看出：这个事件出了多少货、增加了多少应收、责任人是谁、交易对手是谁。业务部门问“怎么回事”的时候，这个结果基本就是第一手的答案。

4. 落地 REA 模型时的数据库设计与服务端实现要点

4.1 单一事件表还是分事件类型表

在设计 economic_events 的时候，我纠结过一段时间：把所有事件都放在一张表里，还是销售、收款、退货各建一张表。最终的建议是：小规模系统先做单表加 type 字段，跨业务的查询简单；一旦事件类型超过六种，或者某类事件有大量独有属性，再考虑分表。

单表模式的代价是公共字段会稍微粗糙，比如 reference_no 对销售事件是订单号，对收款事件是银行流水号，语义不完全一样。解决办法是加一个 source_system 字段来区分来源，而不是为了语义拼命拆字段。事件表的核心职责是记录“发生过什么”，独有细节可以放到配套的扩展表里，没必要一次性建模到完美。

4.2 事件只追加，不修改

REA 落地时最重要的工程约束是事件不可变。一笔销售事件一旦写入，就不应该被 update。如果发现录错了，正确的做法是新增一条冲正事件，例如“销售退回”，再用经济链挂到原来的销售事件上。

这个约束平时看起来很教条，但到了对账和审计的时候才知道有多值钱。原因在于，覆写式更新会破坏“存量-流量”平衡，今天的库存余额对不上昨天的库存流水时，你根本无法定位是哪一笔 update 把数据改没了。而事件追加制天然保留了证据，残缺数据可以通过扫描事件链定位。

我见过不少团队在重构数据模型时，因为习惯了 update 思维，最后又悄悄把事件表改成了可变表。等到年终审计拿不出历史链，才回头加班补数据。这个教训写在这里，希望后来人少走一次。

4.3 API 层怎么划分

服务端接口建议按“写事件”和“查链条”两条线来设计。写事件接口负责接收业务命令并落事件，查链条接口负责把事件、资源、代理人关联起来投影成业务视图。

一个典型的“创建销售事件”接口入参，应该同时包含资源流、内部代理人、外部代理人和参考号。我把这些封装在一个请求里提交，保证库表写入在一个事务中完成。查询接口则尽量不带复杂过滤条件，而是围绕事件ID、客户ID、供应商ID、资源ID、参考号这几个维度提供查询能力。

需要特别注意的是，不要在写事件时同步去做大量计算。比如“实时库存余额”不要每次都扫描事件表生成，而是维护一个预聚合的“资源当前存量视图”。写事件成功后通过消息或定时任务增量更新这个视图，性能会好很多。

4.4 资源平衡校验写在哪个环节

资源-事件关系有一个很好的性质：同一事件关联的流入流出在数量上应当守恒，才符合业务直觉。库存流出2件服务器的同时，如果应收账款流入只记了1万而不是2万，这肯定是录错了。

校验可以放在服务端事务里，先查该事件涉及资源的当前可用量，再判断方向为 OUT 的记录是否超卖。并发场景下要小心超卖问题，我一般会对资源主键加行锁，或者用乐观锁版本号，保证同一个资源的两个并发事件不会同时通过校验。

后台还需要一个异步对账任务，周期性扫描事件资源关联表，找出流入流出不守恒的记录。这个任务其实就是把校验从“写入时前置拦截”变成“事后查漏补缺”，两类机制配合，数据质量才算有兜底。

5. 踩过的坑：从“看起来合理”到“真正好用”的四个修正

5.1 把“资源”当成“科目”来建

第一次重构时，我顺手把“销售收入”建成了一个资源，把“主营业务成本”也建成了资源。结果模型跑起来后，我感觉自己只是换了一张皮，本质上还是借贷科目表，因为“销售收入”根本不是被控制、可交换的资源，它是事件的产出结果。

修正方法是把资源收窄到真实可控制、可计量的对象上：库存商品、现金、应收账款、应付账款、固定资产。收益类项目不要建模成资源，它们应该是事件之后通过聚合计算得到的指标。最好的判断标准是问一句：这个对象能被某个人或组织“控制”和“转移”吗？销售收入控制不了，也转移不了，所以它不是资源。

5.2 忘了显式维护事件链

我最初以为，销售事件和收款事件之间只要共享一个客户ID或者订单号，查询时自然能连起来。但后来发现，这种隐式关联在数据量上来之后根本不可靠。同一客户的十笔销售和五笔收款，如果不显式指定哪笔销售对应哪笔收款，就会出现“张冠李戴”的配对风险。

修正方法是显式维护 event_event_links。每一笔收款事件创建时，明确指定它的前序销售事件ID。如果是一笔回款同时覆盖多笔订单，就拆成多条收款事件明细，或者用回款分配表来处理。这个操作在建模阶段看着繁琐，但对账时就是救命稻草。

5.3 代理人不落历史版本

业务正常运行时，agents 表里的客户名称和员工姓名会频繁变化。客户可以改公司名，员工可以调岗离职。如果直接更新 agents 表，历史上的销售事件就会关联到新名字，看起来像昨天还是某员工经手的业务，今天却变成了别人。

修正方法是给代理人增加版本机制。不要直接覆写 display_name，而是在 agents 表旁边增加 agent_versions 表，记录版本生效时间。事件关联的是代理人主键加版本时间，或者更简单一点，在 event_agent_links 里冗余保存参与人当时的名称和角色。数据冗余在这里是值得的，因为审计场景下“当时是谁”远比“现在是谁”更重要。

5.4 只存一个时间戳导致的同日乱账

业务时间和入账时间是两回事。仓库是凌晨0点后盘点的，财务是第二天上午10点才确认入账的；跨时区项目更是如此。如果事件表只有一个 created_at，查询“当天销售金额”时就会出现口径差。

修正方法是把 occurred_at 和 recorded_at 分开。occurred_at 是业务实际发生时间，用于日报、运营分析；recorded_at 是系统落库时间，用于数据接入监控和账务确认。两张时间字段分工明确，很多争议问题都会瞬间消失。

6. REA 在数据中台、实时分析和审计里的扩展玩法

6.1 把 REA 事件作为中台统一事实层

数据中台里最麻烦的问题之一是各系统口径不统一。订单系统说“成交”，财务系统说“开票”，物流系统说“发货”，三套口径放在一起根本对不上。REA 的价值在于，它以“经济事件”为统一事实中心，各系统只需要把事件映射进来，后续的指标计算都基于同一套事件流。

例如销售收入指标，在中台里不是从订单表取数，而是从 economic_events 中 event_type='SALE' 的事件里去聚合。终端用户看到的指标口径，可以追溯到具体事件、资源、代理人和原始系统参考号。这种可解释性对管理驾驶舱来说非常重要。

6.2 存量-流量平衡校验：实时反异常识别

事件资源关联表天然支持一种反向检测玩法。正常业务事件往往同时涉及资源流入和流出，比如销售事件出库存、进应收。如果扫描发现某个事件只有流出没有流入，或者数量明显不对等，那就有可能是漏录、错录甚至虚构业务。

这种平衡扫描可以做成定时任务，也可以做成实时流计算。对金融类系统来说，类似的平衡校验早就应用到清算对账里了；对电商和供应链系统，把它用起来也能发现很多数据幽灵。这里给一个简单的 SQL 示例，找出流入流出数量不守恒的事件：

SELECT el.event_id, SUM(CASE WHEN el.direction = 'IN' THEN el.quantity END) AS in_qty, SUM(CASE WHEN el.direction = 'OUT' THEN el.quantity END) AS out_qty FROM event_resource_links el GROUP BY el.event_id HAVING in_qty IS NULL OR out_qty IS NULL OR ABS(COALESCE(in_qty,0) - COALESCE(out_qty,0)) > 0.0001;

注意，这只是示意。真实的销售事件中“库存流出2件”和“应收账款流入2万元”二者数量单位不同，不能直接相减。实际做平衡校验时需要按资源类型分别定义守恒规则，比如数量资源看数量，金额资源看金额，或者用统一的金额维度做折算。关键思路是一样的：流向一个方向的资源变化，往往要对应另一个方向的资源变化，否则就可能藏问题。

6.3 审计场景下的证据链追踪

审计人员最常问的问题是三个：这笔业务发生了什么、谁经手的、下一步去了哪里。REA 模型刚好把这三个问题的答案结构化了。从一笔销售事件出发，向前经 event_event_links 能查到后续收款事件，向后经 reference_no 能查到原始订单，向左右经 event_agent_links 能查到责任人和客户。

我在项目实践中发现，这套模型让外部审计沟通成本低了很多。审计通常不需要看几十行财务 PID 调整，只要看到一张“事件-资源-代理人”的关联图，就能理解业务流程和数据流转逻辑。如果你所在的行业对审计追踪有硬性要求，REA 路线值得认真考虑。

6.4 与事件溯源、DDD 的相互配合

REA 和 Event Sourcing（事件溯源）的关系非常微妙。事件溯源要求系统状态由事件流派生，REA 则要求业务建模围绕经济事件展开。两者虽然来源不同，但在工程实践中可以结合。我实际采用的方案是：核心审计域用 REA 概念建模，保存不可变的经济事件；读模型从事件流投影出来，支撑页面展示和报表查询。

配合领域驱动设计时，REA 还可以帮助划分聚合边界。比如库存资源是一个聚合，销售事件是另一个聚合，它们之间通过事件消息完成最终一致。聚合根不必全按 REA 对象来，但核心事件的定义和命名可以直接借鉴 REA 的事件语义。这样一套组合下来，系统既能满足关系型数据库时代的报表习惯，又能往实时流架构平滑演进。

7. 最后聊聊我在实践中的感受和一点小建议

REA 不是万能的。如果是内容管理、展示型网站、简单的个人工具，强行套用资源-事件-代理人反而会把模型弄复杂。它最适用的场景是那种业务流程错综复杂、审计要求高、需要跨系统对账的企业级应用，比如供应链、财务、电商交易、资产管理。我个人的体会是：当你发现用传统建模方式回答“发生了什么”越来越困难时，就是换 REA 视角的最佳时机。

这个模型最反直觉的一点是，它要求开发者先放弃“稳定的名词表”，先整理出一张“动词清单”。但商业业务本质上就是一连串动作构成的循环：买入、生产、销售、回款、再买入。把动作作为建模中心，名词作为动作的附属对象，数据架构反而会更贴近业务真实路径。

提示：如果你第一次试验 REA，不要追求学术完整性，先做一个极简版。只需要三张主表和三张关联表，把销售和收款两个事件串起来，跑通一条证据链，你就能直观感受到“事件中心”和“科目中心”的本质差异。

说到最后，分享一个小技巧。我在启动新系统设计的时候，会先拉上业务侧的同学，让他们讲最近三个高频动作，比如“销售、发货、收款”。然后我在白板上给每个动作画一个小卡片，左边写资源变化，右边写参与角色，上方写下个动作链接。画完这三张卡片，数据库表结构其实已经有一个靠谱的雏形了。这套做法让我少踩了非常多返工的坑，希望能给你也省下一些时间。