REA模型：用资源、事件和参与者重构业务领域建模-平芜编程栈

做企业系统设计这些年，每次和人讨论业务建模，绕不开一个缩写：REA。这三个字母对应 Resource（资源）、Event（事件）、Agent（参与者），是会计信息系统领域里一套经典到不能再经典的领域建模框架。很多人第一次听到REA都会下意识以为是拼写错误，其实它很早就被学术界提出来了，到今天依然是设计订单、库存、财务这类核心系统时相当值得参考的抽象方式。

我最早接触REA是在负责某跨平台订单系统的重构时，老系统里订单表、流水表、科目表纠缠在一起，每次对账都要写十几段临时SQL，后来换成REA思路重新梳理领域模型，表结构清晰了一大截。这篇内容就围绕REA这套模型展开，讲清楚它解决了什么问题、在实操中怎么落成代码、有哪些坑要躲，适合正在做交易、库存、财务相关系统的开发者，也适合想规范业务建模的产品经理和架构师。

1. 先搞清楚REA到底是什么

1.1 三个字母的完整拆解

REA不是某个开源框架的名字，而是一种抽象业务的思维方式。它把任何一个商业活动拆成三种最基本的元素：

Resource（资源）：被交换或消耗的东西。钱是资源，商品是资源，服务也是资源。它回答的是“我们的业务到底围绕什么在转”。
Event（事件）：真正发生的业务动作。下单不是事件，严格说“客户提交订单”才是一个事件；“财务确认收款”是另一个事件。它回答的是“业务流程里到底发生过什么”。
Agent（参与者）：发起或参与事件的个人、组织或系统。客户、供应商、销售员、库管员甚至第三方支付平台，都是Agent。它回答的是“谁在这个环节里做了什么”。

很多人在第一次接触时会觉得这太抽象，其实换个说法就通了：REA就是在问三个问题——什么东西（资源）、发生了什么（事件）、谁干的（参与者）。把这三个维度组合起来，一套业务的骨架就出来了。

1.2 一句话理解：业务本质是“事件流”

我见过太多团队在建模时一上来就画表结构，订单表、订单明细表、支付表、退款表，画完以后发现业务改了一个状态，所有表都要跟着改。REA的思路刚好反过来：先不要关心最终数据库长什么样，先关心业务里“发生过哪些事件”，然后把事件串成一条时间线。

这条时间线就是“事件流”。举个例子，一次完整销售不是一个对象，而是由一串事件组成的：

客户提交订单（事件一）
仓库确认可发货（事件二）
商品出库（事件三）
客户确认收货（事件四）
财务确认收款（事件五）

每一个事件发生时，都会涉及一些资源和参与者。订单状态不是某个字段被改来改去，而是这串事件按顺序发生后的自然结果。状态只是对“已经发生过哪些事件”的一个投影，本身不应该是唯一的真相。

1.3 REA和传统记账模型差在哪

传统记账模型的核心是“借贷”，账上记录的是“借方科目”和“贷方科目”，它更关心钱和资产在账户间怎么流动。REA模型的核心是“事件”，它更关心“业务事实”本身。这两个视角在实际系统里经常打架。

举个例子，传统财务账里，“销售商品给客户”会被拆成一笔“应收账款增加”和一笔“库存商品减少”。分录是正确的，但它隐藏了业务上下文：哪个客户、哪个订单、哪个仓管员经手、什么时候签收的。REA模型则会把销售这件事描述成一个“销售事件”，关联到商品（资源）、客户（Agent）、销售员（Agent），再单独用一条“提货事件”或“收款事件”去反映货物的转移和资金的流入。

从设计角度来看，两种模型也不是互斥的。REA可以用来做领域建模和业务流程梳理，传统借贷记账可以体现在财务模块的账务处理层。很多成熟系统实际上是两层结构：上层是REA式的事件记录，下层是面向报表和审计的借贷分录。理解了这一点，后面落地时就少很多纠结。

对比点	传统记账模型	REA模型
核心关注	资金流动、借贷平衡	业务事实、事件序列
最小单位	会计科目 + 借贷金额	资源 + 事件 + 参与者
业务上下文	弱，需要额外关联	强，天然带上资源和参与者
扩展性	加科目、加表结构	加事件、加资源类型
适合场景	财务报表、法定核算	业务分析、系统建模、审计追踪

2. 为什么REA适合做业务建模

2.1 从“对账对不上”这个老问题说起

做过交易系统的人应该都有这种体验：订单表里有几十个状态，支付系统回调之后要把状态改成“已支付”，库存系统那边还要扣减库存，如果某个环节失败，状态就卡住了。月底对账时，财务说钱对上了，仓库说货对上了，但系统里三条链路的对账结果却对不上。为什么？

因为订单、支付、库存本质上是同一件事的不同投影，业务事件只有一个，却被拆到了三张各管各的表里。订单表里的状态字段记录的是“业务走到哪一步”，支付流水记录的是“钱从哪来、到哪去”，库存流水记录的是“货怎么进出”。三者之间没有任何共同的对象，只能靠订单编号硬关联。一旦出现异常，就很难判断到底是哪个环节出了问题。

REA把这三块重新统一起来：把“支付成功”和“出库完成”都看作是同一个业务过程里的事件，它们共享相同的资源对象（钱、库存）和参与者。对账时不是拿三张表去比对状态，而是追问“这笔业务的事件链是否完整”。事件链不完整，答案很快就会暴露在审计日志里。

2.2 REA模型的四大核心优势

第一，可审计性天然强。因为每个业务事实都被记录为事件，而且事件是不可变的，想追溯一笔订单从创建到完结的所有路径，只需要按时间查询事件表就够了。这对财务审计、风控、客服查证都有很大价值。

第二，业务规则更有弹性。传统模型里，每增加一种业务类型，比如新增“预售”“积分抵扣”“零元购”，常常要调整库表结构和状态机。REA模型里，这些都只是新的事件类型或新的资源关联，核心表结构可以保持相对稳定。

第三，状态不再双向污染。REA不鼓励直接用“订单状态”去判断业务，而是通过“事件是否发生”来判断。这样代码里就不会出现“如果状态等于A且支付时间大于B且库存流水存在”这种连环条件，逻辑清晰很多。

第四，为事件溯源和微服务拆分留了口子。REA本身就是一套事件驱动的思考方式，天然贴近事件溯源（Event Sourcing）架构。如果未来想按领域拆服务，REA可以作为划分领域的边界参考。

2.3 什么时候用、什么时候别硬用

REA也不是万能膏药。如果只是一个简单的内容管理网站，或者一个纯信息展示系统，没有复杂的资源交换，用REA只会徒增抽象层级。它的价值主要体现在资源交换频繁、涉及多方参与者、需要严格追踪业务过程的场景。

判断标准很简单：你的系统里是否存在“一组资源在多个参与者之间转移”的核心流程？比如电商订单、库存调拨、会员储值、报销审批里的“金额”和“审批单”在多个人之间流转，这些都适用。反之，如果核心业务只是“用户发帖、管理员审核”，那直接建表更高效。

3. 核心概念拆解与实操要点

3.1 Resource（资源）：不只是“资产”

很多人在建模时容易把Resource理解成“数据库里的一张资源表”，然后只存“商品名称、单价、库存数量”。但REA里的Resource要有“可交换”“可消耗”的属性。钱、商品、服务、积分都是资源，甚至连“一次技术咨询的时长”也可以是资源。

在实操中，我倾向于把资源分成两类：存量型和增量型。存量型资源关注“当前余额”或“当前库存”，比如仓库里的商品数量；增量型资源则是一条条发生的具体流量，比如“入库单”和“出库单”。这两种资源在REA里会互相联系，典型的设计是：资源主数据（存量）负责描述资源的属性，资源变动记录（增量）负责描述资源的变化历史。

注意：不要把资源直接等同于传统数据库里的“库存字段”。库存字段是结果，资源变动记录才是事实。命令式扣库存会丢失谁在什么时间做了什么，用资源变动事件来驱动，才符合REA的初衷。

3.2 Event（事件）：一切从“发生”开始

Event在REA里是最关键的一类对象，也是和普通业务表差异最大的地方。它记录的是一个已经发生的、不可撤销的业务事实。所以设计事件时，最核心的约束就是“不更新、不删除”，只能追加新事件来修正旧事件。

比如订单被客户取消，不应该在订单表里把状态从“已提交”改成“已取消”，而是应该新增一个“订单取消事件”。原始“订单提交事件”还留在那里，只是新事件表示后续发生了取消。这样任何时候回放事件链，都能知道这笔订单经历了什么。

事件还有一个分类习惯：按业务的“承诺”和“执行”拆开。下单是承诺，发货是执行；生成采购订单是承诺，供应商发货是执行。承诺事件先确定意图，执行事件再说结果。这种拆分对现金流、物流追踪、库存预留都有很大帮助。

3.3 Agent（参与者）：谁做了什么

Agent指的不一定是自然人，也可能是部门、系统、合作伙伴。比如“自动风控审核”这个动作，参与者是一个系统Agent。把参与者独立建模，是为了回答“谁在什么时间对什么资源做了什么”，也是为了满足审计要求。

在具体设计里，Agent可以和用户体系打通，但要注意区分“业务参与者”和“系统操作者”。业务参与者是报价单里的客户、供应商；系统操作者是后台录单的运营人员。一张订单里，客户和运营人员可能是同一个人，但语义不同，建议分别建模，不要共用同一个字段。

3.4 三条核心关系链

REA模型不只是一堆类，它靠关系链把业务规则串起来。我最常用的三条关系链是：

资源与事件的关系：事件影响资源，比如“销售发货”事件减少“可售库存”，“收款”事件增加“现金”。通常用一对多的双向关联表达。
事件与事件的关系：多个事件之间形成因果或先后关系，比如“采购入库”触发“应付账款增加”，“付款”触发“应付账款减少”。一组相互依赖的事件形成“交换循环”。
事件与参与者的关系：外部参与者发起事件，内部参与者执行事件。比如“客户”发起“退货申请”，“客服”执行“退货审核通过”。

这三条关系链一旦梳理清楚，业务的闭环基本就清楚了。剩下的问题只是技术选型和编码落地。

3.5 一个完整REA片段：从下单到收款

拿电商订单举例，完整REA片段可以这样画：

客户（Agent）提交订单（事件1），关联商品资源（Resource）和客户（Agent）。
仓库（Agent）完成发货（事件2），减少商品资源（Resource），关联到订单（Event1）。
财务（Agent）确认收款（事件3），增加现金资源（Resource），关联到订单（Event1）。

这里可以看到，订单实体本身不是REA必须的东西，订单编号更像是“事件链的聚合根”，用于把一组相关事件串起来。这个差别非常微妙：传统设计是先有订单，再往订单上挂支付、发货；REA设计是先有事件，再把同一业务ID的事件聚合起来。实现时我会同时保留业务ID字段，方便查询和聚合。

4. 落地实现：从模型到代码

4.1 领域对象定义

把REA模型翻译成代码，第一版不需要太复杂。我建议先建这几个核心类：ResourceDescriptor（资源描述）、BusinessEvent（业务事件）、Agent（参与者）、EventRelation（事件关联）。用Java风格写的话，大概长这样：

public class BusinessEvent { private String eventId; private String bizId; // 聚合根，比如订单号 private EventType type; // 提交订单、发货、收款... private LocalDateTime occurredAt; private List<ResourceChange> resourceChanges; private List<AgentRef> participants; private Map<String, Object> payload; // 原始上下文 }

ResourceChange是资源变动记录，用来表示这个事件对哪些资源产生了影响：

public class ResourceChange { private ResourceType resourceType; // 商品、现金、积分 private String resourceId; // 具体资源实例，比如SKU private BigDecimal quantity; // 正数表示流入，负数表示流出 }

这样设计之后，一个“销售发货”事件就是一个BusinessEvent，它的resourceChanges里有一条“商品SKU数量-1”的记录，participants里有仓库Agent和销售Agent。订单号bizId把多个事件串起来，回放时只需要按bizId查询。

4.2 数据库表设计

数据库层面，我习惯用五张核心表加若干扩展表：

resource_descriptor：资源主数据，描述商品的SKU、名称、规格。
agent：参与者表，客户、仓库、系统账号统一存储。
business_event：事件主表，存eventId、bizId、eventType、occurredAt。
resource_change：资源变动明细，每个事件关联多条资源变动。
event_agent_rel：事件和参与者的关联表。

下单、发货、收款都别去修改同一张“订单”表，而是各自插入新的事件。订单信息可以在事务里通过事件快照生成一个“订单视图表”供查询，但真相来源始终是business_event表。

表结构可以按这个思路建：

CREATE TABLE business_event ( event_id VARCHAR(64) PRIMARY KEY, biz_id VARCHAR(64) NOT NULL, event_type VARCHAR(32) NOT NULL, occurred_at TIMESTAMP NOT NULL, payload_json TEXT, INDEX idx_biz_id (biz_id) ); CREATE TABLE resource_change ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id VARCHAR(64) NOT NULL, resource_type VARCHAR(32) NOT NULL, resource_id VARCHAR(64) NOT NULL, quantity DECIMAL(18,4) NOT NULL, INDEX idx_resource (resource_type, resource_id), INDEX idx_event (event_id) );

注意resource_change里的quantity是带符号的，正数代表资源流入，负数代表资源流出。查询某个资源的当前余量时，就是对该资源所有resource_change的quantity求和。这种做法的好处是，任何一笔余量变化都能追回到对应事件。

4.3 服务层如何编排事件

服务层的核心职责是“保证事件按正确顺序写入，并在多个资源之间保持一致性”。这句话说起来简单，做起来要留意事务边界。

以“订单支付”为例，服务层要做三件事：

校验支付回调信息是否合法。
写入“支付成功”事件，同时写一条resource_change，把“客户预存款”或“外部入账”增加对应金额。
检查订单事件链是否已经满足发货条件，如果满足，触发“待发货”的后续流程。

这三件事最好放在一个本地事务里完成，避免事件表和资源变动表不一致。如果支付回调具有幂等性，还要在写入事件前校验“同一个bizId是否已经存在相同event_type”，防止重复入账。

这里有一个实操细节：不要把业务逻辑写进事件表本身，事件表只负责记录。业务判断，比如“是否允许退款”，应该通过读取事件链自己推导，或者由领域服务来决策。这样才能让事件数据保持纯粹的“事实记录”属性。

4.4 查询与读模型

事件只增不改，会给常规查询带来麻烦：每一次查询都要聚合一堆事件，如果业务量大了，性能很难看。我的经验是采用“事件驱动 + 读模型”的组合：写路径走事件，读路径用单独的表或视图展示最终状态。

比如订单查询页需要展示“订单状态、支付状态、发货状态”，可以创建一个order_read_model表，在事件写入后通过异步监听或事务回调更新它。查询时直接读这个读模型，不实时聚合事件。这样事件表依然保留完整审计链，读模型则负责高性能查询。

读模型的更新要注意一致性延迟。如果业务允许最终一致，可以异步更新；如果要求强一致，就在同一事务里同步更新读模型。对于多数交易系统，我建议核心的支付、库存、账户余额采用同步更新，非核心的报表数据采用异步更新。

5. 常见问题与实战排查

5.1 事件和流水一样吗

很多初学者会把REA的Event等同于支付流水。支付流水是资源变动的一部分，Event则是包含资源变动、参与者、业务上下文在内的完整事实。比如“订单退款”事件里，不仅有资金流出记录，还有退款原因、审批人、原订单关联。流水只是从资金维度投影出来的结果。

如果开发时发现事件表里只有流水字段，没有业务上下文，说明又回到了流水账式的设计。补救方法也比较直接：在事件对象里加一个payload字段，把请求参数、审批备注等上下文都存进去。事件表乱一点没关系，但事实必须完整。

5.2 库存扣减放在哪个环节

库存扣减是最容易踩坑的地方。有人在下单时直接扣库存，有人支付成功后才扣，有的则是在出库时扣。从REA角度看，库存扣减本质上是一个“出库事件”，不该把它和“下单事件”“支付事件”混为一谈。不过业务上确实需要“锁定库存”来避免超卖，所以实操中可以把“库存锁定”建模成一个独立的“承诺事件”：

下单时新增“预占库存”事件，资源变动为“可售库存减少、锁定库存增加”。
支付成功后新增“确认出库”事件，资源变动为“锁定库存减少、已售库存增加”。
订单取消时新增“释放锁定”事件，资源变动为“锁定库存减少、可售库存增加”。

这种设计既保留了库存变动轨迹，又不会在下单阶段直接削减真实库存。前提是库存资源可以区分“可售、锁定、已售”这几个维度，实现上本质上就是多增加几类resource_change，而不是把库存字段揉在一起。

5.3 事件只增不改的数据膨胀怎么办

事件表只增不改，运行半年后数据量确实会很大，尤其像resource_change这种明细表。我的处理策略是分层归档加冷热分离：

热数据：最近3个月到6个月的事件，保持在线，用于日常查询和运营分析。
冷数据：超过6个月的事件，定期迁移到历史库或数仓，核心查询不再直接访问。
汇总表：对历史数据做预处理，比如每天统计各资源的累计流入流出，导入到报表表里。

要注意，迁移前必须保证事件链的完整性。如果一个bizId的某些事件已经归档，而另一些事件还在热库，按bizId聚合时就会缺数据。我通常会给事件表增加一个archive_version字段，迁移时按bizId整组迁移，而不是按时间单条迁移。这样事件链永远完整，查询时也能判断数据落在哪个层。

5.4 和财务系统对账怎么设计

REA模型落地时，财务团队最关心的还是借贷分录。我的做法是在事件层和财务账务层之间做一个映射器：每当一个业务事件写入后，映射器根据事件类型生成对应的会计凭证，写入财务系统。比如“确认收款”事件生成“借：银行存款，贷：应收账款”的分录。

这个映射器不要散落到业务代码里，最好集中在一个模块维护。每新增一种事件类型，就在映射器里新增一条规则。这样可以保证业务系统和财务口径是解耦的，又不会因为事件规则的增加把账务代码改得到处都是。

如果对账出现不一致，排查顺序一般是先查业务事件是否完整，再查映射器是否按照预期生成凭证，最后查财务系统是否成功接收。大多数情况下，问题都出在“事件已经写入，但映射器没有执行成功”，这时候幂等重放映射器的逻辑就很关键。

5.5 实操速查表

症状	可能原因	处理方案
订单状态和支付状态对不上	事件写入顺序不一致	统一用biz_id串事件链，按occurredAt回放
库存扣成负数	没有区分“预占”和“实际出库”	增加锁定库存事件，用独立事件表达
对账缺凭证	映射器未执行或失败	增加映射器重试和幂等记录
事件表越来越大	没有冷热分离	按bizId整组归档，保存archive_version
查询聚合很慢	每次都实时聚合事件	建立读模型，事件写入后同步更新

在实际操盘项目里，我最深的体会是：REA真正的价值不在某个具体类或表上，而在于逼着你在写代码之前把“业务发生了什么”想清楚。很多团队宁可花两周讨论微服务架构，也不愿意花半天画一张REA事件图，最后系统上线后才发现订单、库存、财务三套逻辑互相打架。如果你也想重构一套交易系统，我建议先别急着拆服务，拿出几个核心流程，用资源和事件把链路走一遍。画完那张图，很多表结构上的纠结会自然消失。