我第一次看到“rea”这个词是在一套业务系统的旧代码注释里。当时没人能说清它到底代表什么直到把整个库存模块的领域逻辑理顺我才反应过来它其实是 Resource、Event、Agent 的缩写——一种非常经典的企业业务建模内核。简单说REA 把任何业务都看成三件事资源Resource在系统内外流动事件Event触发这些流动参与者Agent决定并执行事件。它特别适合做订单、库存、收支、审批这一类需要追溯和审计的业务模块。如果你正在设计账务核心、供应链系统或者想把那些到处乱飞的 status 字段改成可追溯、可对账的领域模型这个模式值得你花时间吃透。以我自己的经验REA 不是一个前端框架也不是某个具体平台的 API。它是一套分析业务的语言不绑定某种数据库也不限制编程语言你可以在传统关系库里落地也可以在事件溯源架构里实践。这篇文章我会用一个电商库存的例子把 REA 的核心概念、数据模型、落地代码和踩坑经验一次讲清楚。1. REA 到底是什么被低估的业务建模内核1.1 三个基本元素Resource、Event、AgentREA 把业务世界抽象成三个角色。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. 实操把一个传统库存系统重构为 REA3.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 100direction 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 是一个被反复验证过的思考框架。我先从“资源被事件改变参与者决定事件”这四个字开始你会发现自己对业务模型的理解会慢慢变得不一样。