我第一次看到“rea”这个词，是在一套业务系统的旧代码注释里。当时没人能说清它到底代表什么，直到把整个库存模块的领域逻辑理顺，我才反应过来，它其实是 Resource、Event、Agent 的缩写——一种非常经典的企业业务建模内核。
简单说，REA 把任何业务都看成三件事：资源（Resource）在系统内外流动，事件（Event）触发这些流动，参与者（Agent）决定并执行事件。它特别适合做订单、库存、收支、审批这一类需要追溯和审计的业务模块。如果你正在设计账务核心、供应链系统，或者想把那些到处乱飞的 status 字段改成可追溯、可对账的领域模型，这个模式值得你花时间吃透。
以我自己的经验，REA 不是一个前端框架，也不是某个具体平台的 API。它是一套分析业务的语言，不绑定某种数据库，也不限制编程语言，你可以在传统关系库里落地，也可以在事件溯源架构里实践。这篇文章我会用一个电商库存的例子，把 REA 的核心概念、数据模型、落地代码和踩坑经验一次讲清楚。
1. REA 到底是什么：被低估的业务建模内核
1.1 三个基本元素：Resource、Event、Agent
REA 把业务世界抽象成三个角色。
Resource 是“有价值的东西”。它不一定是货架上的商品，也可以是虚拟权益、服务工时、账户余额、审批额度、优惠券，甚至是一段已经交付的物流服务。在系统里，Resource 不只是一条数据库记录，它必须承载“可以被交易、被消耗、被转换”的业务语义。比如库存表里的 SKU 是资源，客户账户里的积分也是资源。
Event 是“让资源发生变化的事情”。采购入库、销售出库、支付、退款、领用、报废，这些都是事件。事件必须包含三个关键信息：什么时候发生、谁参与、对哪些资源产生了多大变化。事件是 REA 里最重要的一层，因为它才是业务事实本身。
Agent 是“参与事件的个人或组织”。它可以是内部的仓库管理员、销售员、系统机器人，也可以是外部的客户、供应商、物流公司。每个事件至少要有一个发起方和一个接收方，否则资源流动就没有方向，后面的对账和权限控制会很麻烦。
用生活化的类比来理解：Resource 像一锅正在煮的汤，Event 是每次加菜或盛汤的动作，Agent 是拿着勺子的那个人。你只记录“现在锅里有什么”是不够的，真正能回答“这锅汤为什么变成现在这个味道”的，是那些加菜和盛汤的历史动作。
1.2 为什么只靠“状态字段”远远不够
传统系统的建模习惯是给业务对象加状态。比如订单表里有个status，从pending变成paid再变成shipped。这种模型写起来很快，但用久了问题非常明显。
第一个问题是过程丢失。你只知道现在订单是“已发货”，但不知道它是几点发货的、谁发的货、出库数量是否和订单一致、当时有没有发生破损补发。状态只是一个结果快照，结果背后的因果链断了。
第二个问题是口径混乱。同一个订单，财务看“应收”，仓库看“出库”，客服看“物流节点”，如果大家都去更新同一个状态字段，最后一定会出现“谁覆盖谁”的撕扯。状态字段本质上是在混合多个领域的语义。
第三个问题是审计困难。业务出偏差时，你翻遍日志也拼不出完整事实，因为日志是技术细节，不是业务事件。REA 的思路完全不同：它不把状态当作唯一真理，而是把“导致状态变化的事件”当作事实。当前状态可以被随时重算，业务过程天然留痕。
| 对比项 | 传统状态字段建模 | REA 事件建模 |
|---|---|---|
| 核心关注点 | 当前状态是什么 | 状态为什么变成这样 |
| 历史追溯 | 难，依赖操作日志 | 天然完整，事件流可回放 |
| 多部门口径 | 容易互相覆盖 | 各自从事件投影所需视图 |
| 数据订正 | 直接改字段 | 新增订正事件 |
| 对账能力 | 弱，只能查余表 | 强，可由事件重算 |
2. REA 建模的核心细节：从理论到可落地
2.1 一个电商订单的 REA 拆解
理论说多了容易飘，我用一个标准电商销售订单来拆解。
假设客户拍下一件商品并完成支付。这个业务流程在 REA 视角下会被切分成多个事件。
- 订单确认事件：客户承诺购买，系统承诺交付，产生“应收款”资源。
- 商品出库事件：库存资源减少，商品离开仓库，物资的所有权转移给客户，产生“已发货商品”这类在途资源。
- 收款事件：客户支付，现金资源增加，应收款资源减少。
- 发货完成事件：在途资源转化为客户已收货权益。
用表格表示更直观。
| 业务动作 | REA 事件 | 受影响资源 | 参与 Agent |
|---|---|---|---|
| 下单 | 订单确认 | 应收款 +，库存承诺量 + | 客户、销售系统 |
| 出库 | 库存出库 | 实物库存 -，在途商品 + | 仓库员、运输方 |
| 支付 | 收款 | 现金 +，应收款 - | 客户、财务系统 |
| 签收 | 交付完成 | 在途商品 -，客户权益 + | 客户、物流方 |
这里有一个关键认知：一个订单不是一条状态记录，而是一串事件序列。每次写代码时，不要问“订单现在处于什么状态”，而要问“给这个订单追加一个什么事件”。这样思考问题，业务边界会清晰很多。
2.2 二元关系与方向：inflow / outflow 的语义
REA 里事件与资源的关联是有方向的。一个事件对资源要么是流入，要么是流出。
库存出库事件对“实物库存”来说是 outflow，因为商品从这个资源池里出去了；同一笔事件对“在途商品”来说是 inflow，因为新的资源形态出现了。收款事件对“现金”是 inflow，对“应收款”是 outflow，因为债权被清偿了。
方向不能写错，因为余额是通过方向累加计算出来的。约定inflow 为正、outflow 为负，那么某资源当前量就是所有事件影响的总和。这个规则叫“状态投影”，是 REA 最核心的运算逻辑。
很多团队第一次落地 REA 时只记录“数量变化”，不记录方向，结果导致对账时要去猜正负值。我的建议是：在事件明细表里用direction字段显式存储inflow/outflow，不要用quantity的正负号隐式表达方向。字段越直白，报表和审计越省心。
2.3 状态投影：从事件流推导当前值
REA 系统里，业务资源的当前值并不是直接存储的唯一事实，而是所有相关事件效果的汇总。
假设商品 SKU-1001 有这些事件：
-- 伪 SQL：计算 SKU-1001 的当前库存 select resource_id, sum(case when direction in ('inflow') then quantity when direction in ('outflow') then -quantity else 0 end) as current_balance from event_effect where resource_id = 'SKU-1001' group by resource_id;这样做最大的好处是，任何一条记录都能通过“重放事件”被验证。哪怕某张余额表被写坏了，只要事件明细还在，就能重建结果。
但全部即时扫描事件表在数据量大时性能会变差，所以实际系统通常还会保留一份“投影表”，相当于缓存。每次事件落库后同步更新这张投影表，就既能保证审计性，又不牺牲查询效率。REA 本身只规定事件是事实，至于余额是实时算还是缓存算，属于工程实现，可以按场景取舍。
3. 实操：把一个传统库存系统重构为 REA
3.1 数据模型怎么设计
我实践 REA 时习惯用四类表落地：资源表、参与者表、事件主表、事件效果表。如果是多组织多仓库场景，会再加上资源分类和代理关系表，但核心始终是这四类。
-- 资源目录：库存商品、现金、应收款等都作为资源 create table resource ( id bigint primary key, code varchar(64) not null unique, name varchar(128) not null, resource_type varchar(32) not null, -- inventory / cash / receivable / point unit varchar(16) not null ); -- 参与者：客户、仓库、供应商、系统机器人 create table agent ( id bigint primary key, agent_type varchar(32) not null, -- customer / supplier / warehouse / bot name varchar(128) not null ); -- 事件主表：记录业务事实的头信息 create table business_event ( id bigint primary key, event_type varchar(64) not null, -- purchase_in / sale_out / payment / adjustment occurred_at timestamptz not null, agent_id bigint not null references agent(id), note text ); -- 事件效果表：事件如何影响资源 create table event_effect ( id bigint primary key, event_id bigint not null references business_event(id), resource_id bigint not null references resource(id), direction varchar(16) not null check (direction in ('inflow', 'outflow')), quantity numeric(20, 4) not null, unit_cost numeric(20, 4) );这个模型的精髓在于business_event只表达“发生了什么”，event_effect表达“哪些资源产生了什么样的变化”。如果未来要增加新的影响维度，比如生产批次、仓位、税率，只需要扩展event_effect，或者增加一张效果明细子表，不需要反反复复改业务实体表。
3.2 核心代码流程：事件落库与投影刷新
我写了一个简化版的事件接口逻辑，基于 TypeScript 风格的伪代码，方便说明执行顺序。
async function postEvent(input: { eventType: string; agentId: string; occurredAt: Date; effects: Array<{ resourceId: string; direction: 'inflow' | 'outflow'; quantity: number; }>; idempotencyKey: string; }) { // 幂等检查：用业务幂等键防止重复提交 const existed = await findByEventKey(input.idempotencyKey); if (existed) return existed; return database.transaction(async (tx) => { // 1. 写入事件主表 const event = await tx.insert('business_event').values({ event_type: input.eventType, agent_id: input.agentId, occurred_at: input.occurredAt, }); // 2. 写入事件效果明细 for (const effect of input.effects) { await tx.insert('event_effect').values({ event_id: event.id, resource_id: effect.resourceId, direction: effect.direction, quantity: effect.quantity, }); // 3. 同步更新资源投影表 const delta = effect.direction === 'inflow' ? effect.quantity : -effect.quantity; await tx.increment('resource_balance', { delta }, { resource_id: effect.resourceId }); } return event; }); }这段代码里有三个关键点值得展开。
事务必须同时覆盖“事件写入”和“投影更新”，否则可能出现事件有了但余额没更新，或者余额变了但查不到事件的情况。投影表不强求在同一个事务里更新，但至少要有补偿和重跑机制，否则线上对账会非常痛苦。
幂等键非常重要。事件本质上是不可重复的业务事实，同一次出库如果因为重试被插了两遍，库存就会错。用订单号或者业务流水号作为幂等键，重复请求直接返回第一次的结果，这是 REA 系统必须做的一层防护。
3.3 并发扣减时怎么保证不超卖
REA 是一个分析模式，不是一个并发解决方案，所以并发控制还是要靠数据库事务和锁。
要把“当前余额检查 + 事件写入”做成原子操作，最可靠的办法是在投影表上锁行。
-- 在事务内锁定资源余额行 select balance from resource_balance where resource_id = @resourceId for update; -- 检查余额是否充足 -- 如果充足，写入 event_effect 并扣减余额这里很多人会犯一个错误：只检查资源余额，不检查“承诺量”。在销售场景，还需要考虑已经下单但未出库的扣减承诺。如果不把承诺量纳入资源模型，就很容易出现“账面库存充足，实际可卖库存不足”的超卖问题。解决办法是给资源增加一个committed投影字段，把承诺出库的量和实际出库的量分开统计。
从事件语义上讲，下单时创建一个“库存承诺事件”，它不减少实物库存，但减少可售库存；出库时再创建一个“库存释放/出库事件”，同时扣减实物库存并释放承诺。这样每个环节都有事件支撑，不会出现拍脑袋改数字的情况。
4. REA 落地中的常见问题与排查技巧
4.1 事件允许修改吗？订正不等于 UPDATE
这是我在团队里被问得最多的问题。事件是业务事实，事实是不能被修改的。系统上线后一定会遇到录错了单价、填错了数量、入错了仓库这类人为错误，此时直接UPDATE event_effect会破坏审计链。
正确做法是“新增一个订正事件”，而不是修改原事件。以库存调整为例：
- 原事件：入库 100 件，quantity = 100，direction = inflow。
- 发现实际只有 98 件，那么新增一个订正事件：入库 -2 件，或者调整事件：outflow 2 件。
- 原事件保留不动，订正事件关联
correct_event_id指向原事件。
这样原始事实没有被改变，而最终余额通过事件累加后回到了正确值。审计人员查看历史时，能看到完整的更正轨迹。这种方式虽然看起来多一步，但它保护了业务数据链条的真实性，长期收益远大于直接改库带来的便利。
4.2 事件数据越来越膨胀怎么办
REA 的核心是事件流，所以事件表一定会不断增长。如果每次读库存余额都去全表扫一遍事件效果，再大的数据库也会扛不住。
我常用的方案是“快照 + 增量回放”。每天凌晨生成一张资源余额快照，记录每个资源的历史累计量；当天查询时，从最近的快照出发，只回放该快照之后的事件。这样既能保持事件完整性，又能把查询范围控制在一天数据量内。
如果业务量非常大，还可以进一步做冷热分离。最近三个月的事件放在热表，早期事件归档到冷存储，需要跨月审计时再临时拉取。这个方案的取舍是一致性和实时性之间的平衡，但它能保证系统长期运行不用频繁翻新。
4.3 REA 和 DDD、事件溯源到底什么关系
很多开发者把 REA 理解成一种代码分层框架，其实不是。REA 是领域分析模式，它在 DDD 里扮演的是“领域建模内核”的角色。你可以用 DDD 的限界上下文去划分模块，然后在每个模块内部用 REA 来识别资源和事件。
事件溯源强调“事件的不可变性和重放能力”，REA 则强调“业务语义上的资源流向”。两者可以很好地结合：事件溯源作为存储机制，REA 作为业务语义模型。事件表里存的每条记录就是一个领域事件，而event_effect把这些事件映射为资源的变化。
CQRS 的读模型也可以和 REA 的投影思想互补。REA 里的“事件 → 投影”本质上就是一种 CQRS 写法，写模型只接收事件，读模型按业务需求生成库存视图、财务视图或统计报表。理解了这层关系，你就不会在代码架构上纠结到底用哪种模式了。
5. REA 模式的扩展场景与实战心得
5.1 从库存走向财务：一个模型吃透业务
REA 模型之所以强，是因为它不只适用于库存。我曾在一个模拟项目中用同一套 event_effect 结构同时支撑了库存、佣金和应收应付，效果非常好。
做法很简单：把“应收款”“现金”“服务工时”“积分”也定义成资源，业务事件发生时，事件效果表里同时记录多条资源变化。比如销售事件，库存资源减少 100 元，应收款资源增加 100 元，两者净额为零。这个“资源守恒”的约束一旦建立，系统的对账能力会变得异常强大，所有业务在数据层面自动勾稽，不用再写一堆报表核对 SQL。
引入多币种时，只需给resource增加币种维度，在event_effect里增加原币金额和本位币金额。REA 对底层结构的要求非常少，所以它的可扩展性极好。
5.2 团队落地时怎么降低认知成本
REA 最大的落地障碍不是技术，而是认知转换。团队已经习惯写“更新订单状态”这种代码，突然改成“往事件表插入一条记录”，很多人会觉得绕。
我的经验是不要一开始就画一大堆实体关系图，而是挑一个最痛的点做原型。比如从“库存经常对不上账”切入，先用 REA 把入库、出库、盘点改成事件模型，做出一张可追溯的库存流水页。业务方看到“任何一笔余额都可以往下钻取到具体单据”，往往会很快接受这个思路。
技术侧也一样，不要让开发先去读完整理论，直接给一个最小可运行的示例：两张事件表加一个投影函数，跑通一条出库链路。跑通之后，大家自然能体会到“状态由事件推导”带来的好处。
5.3 我踩过坑之后总结的三条经验
第一，不要把“字典表”直接当成资源。资源必须是可以被事件影响、有数量或金额语义的业务对象。像“商品分类”这类只是维度描述的字典，不应该混入 event_effect，否则资源口径会被污染。
第二，事件时间统一用timestamptz或者 UTC，不要用本地时间。跨时区跨系统的协作场景里，本地时间会导致事件排序混乱，尤其在做余额重放时，时间戳不一致会让结果对不上。
第三，一定要给每个事件设计业务幂等键。技术主键只能保证数据库层面不重复，无法防止业务层面重复操作。幂等键可以用“单据号 + 操作类型”，这个字段的代价很小，但能省掉无数个深夜排查重复入账的半小时。
REA 并不是银弹，它不能帮你解决算法问题，也不能替代缓存设计。但如果你遇到的是业务语义混乱、对账困难、历史无法追溯这一类问题，REA 是一个被反复验证过的思考框架。我先从“资源被事件改变，参与者决定事件”这四个字开始，你会发现自己对业务模型的理解会慢慢变得不一样。
