项目名就叫rea一眼看过去像是随手敲的缩写我接到手的时候差点当成了某个组件库的代号。但认真啃了两天资料之后我确认它其实是REA 资源事件代理建模框架——一个能把业务系统数据模型讲得清清楚楚的老古董级思想虽然 1982 年就有人提出了放到今天照样能打。这篇就聊聊我为什么盯上它、怎么用它在真实项目里落地以及我踩过的那些坑。1. 为什么我盯上了rea这个项目名先说结论REA 不是工具不是中间件也不是某个现成的开源框架而是一套企业业务建模的方法论。它的全称是 Resources-Events-Agents中文可以叫资源-事件-代理人模型。第一次接触的人很容易把它理解成会计系统的理论模型但实际上它的适用范围远不止财务任何需要记录谁、在什么时候、对什么资源、做了什么事的业务系统都可以用 REA 来梳理底层结构。我做过的很多业务系统表面上是订单管理、会员储值、库存进出本质上都在回答同一组问题资源有哪些变化谁发起了这些变化这些变化之间存在什么样的配套关系传统做法是拿到需求直接建订单表、商品表、用户表再把状态字段挂上去。短期内能跑但一旦业务规则膨胀比如订单要拆分、储值要叠加赠送、库存要区分批次表结构就开始打架状态字段越来越多查询越来越难优化。REA 解决问题的思路是反过来先剥离业务事实把发生了什么和业务怎么呈现分开。事件表只存事实订单快照、账户余额、库存数量这些都可以由事件推导出来而不是靠一张张不断打补丁的表去硬存。这个项目的价值点就在这里。它适合三类人看一是被业务系统数据模型折磨的开发想找一种能长期演进的结构二是做领域建模的人想知道传统 DDD 的聚合怎么切才算稳三是技术负责人评估团队建模水平时也可以拿 REA 作为衡量的标尺。我个人最看重的是它把数据库设计与业务发生过程同步这件事从口号变成了可落地的操作原则。2. 先吃透rea的三大核心构件要上手 REA不需要先读一堆论文只需要把三个词在心里揉碎资源、事件、代理人。把它们的关系理顺模型就自己浮出来了。2.1 资源不是你以为的资产资源是系统里有价值且可以被交换或使用的东西。商品是资源现金是资源储值余额是资源甚至员工的工时也可以建模成资源。但要注意REA 里的资源和会计上的资产不是一个概念。资产是资产负债表的视角资源是业务发生逻辑的视角。同样是仓库里的一箱书会计关心它值多少钱REA 关心它是可以被顾客带走、可以被损毁、可以被清仓处理的那个对象。我在建模时习惯先问一个问题这个东西如果从系统里消失业务会不会真的受影响如果会它大概率是资源。比如库存数量减少顾客手里多了一本书这个减少和增多指向的都是资源。反之像订单编号、操作日志这种纯信息型数据就不算资源它们只是事件留下的痕迹。2.2 事件才是真正的业务事实事件是 REA 里最核心的概念它代表业务活动发生在某一时刻的事实。例如顾客买走一本《算法导论》是一个事件顾客充值 200 元是另一个事件。事件必须有明确的时间点而且一旦发生就不能被修改只能被追加新的反冲事件。这一点和审计系统、事件溯源的思路完全一致。很多新手在这里犯迷糊把点击下单当事件。不对提交订单只是系统交互动作它不代表任何经济活动的完成。真正的事件是销售成交——资源从系统里流出收款到账——现金资源流入。下单动作可以触发这两个事件但下单本身不应该占用事件表的一行。建模的时候把系统操作和业务事件分开是保证 REA 模型不乱的第一步。2.3 代理人决定权责归属代理人就是参与事件的个人或组织。顾客买书顾客是代理店员收款店员也是代理供应商补货那家公司是代理。为什么单独把代理人拎出来因为同一笔资源变动站在不同代理人视角看含义完全不同。顾客视角的消费 100 元和门店视角的销售收入 100 元是同一组事件但归属对象不同。实际建模时我一般把代理人分成内部代理和外部代理两类。内部代理是员工、门店、部门外部代理是客户、供应商。这样做的好处是权限系统和审计追踪可以直接建立在 REA 结构上每一笔资源变化都知道是谁经手的、谁受益的、谁承担的。这三个词之间不是并列关系而是有固定的连接规则。资源通过事件发生流入或流出事件由代理人参与事件和事件之间还存在双向性。双向性这个概念很关键一笔销售事件必须对应一笔收款事件或者一笔应收款承诺这样才能构成一个完整的经济循环。菜市场买菜一手交钱一手交货在 REA 里就是销售事件和收款事件成对出现了。会员先储值再消费储值事件和未来某次的消费事件由储值合同约束也是一种双向性。我再拿传统账务系统做一次对比方便理解 REA 到底改变了什么对比维度传统科目表建模REA 建模数据核心借贷分录经济事件记录重点金额变化资源流转的全过程业务可读性需要财务知识解读业务人员可直接看懂状态存储余额表、库存表冗余存储通过事件推导扩展新业务加科目、加字段加事件类型与关联关系审计能力依赖日志表事件本身就是审计证据看完这个对比应该能理解REA 不是对记账系统的颠覆而是一层更贴近业务的元模型。账务系统可以从 REA 模型里生成反过来却很难。3. 用rea给社区书店做一个储值借书系统理论容易越讲越虚我直接拿一个刚结束的模拟项目举例。项目背景是一家社区书店业务有零售图书、会员储值、积分赠送、还有借书还书。老板的需求在业务人员嘴里就是顾客充值 500 送 50买书可以用余额也可以付现金每消费 1 元积 1 分积分可以换小礼品。借书的话每本书押金 50还书退回。需求一听很常规但真去设计表问题马上冒出来赠送的 50 元算不算余额退款的时候送的部分要不要收回积分是消费实时给还是订单完成才给借书押金和储值余额怎么区分如果用状态字段硬怼每个需求都加一个判断系统很快变成一团乱麻。用 REA 重画这些事情一下就理顺了。3.1 业务事件清单先行我没有先去建表而是先拉了一个事件清单。这个项目的核心经济事件其实很少储值充值顾客给收银台现金或转账系统记录充值成功。销售出库顾客带走图书库存下降同时产生应收金额。收款结算顾客用余额或现金完成本次订单支付。借出图书图书记录状态从在馆变成已借出但所有权没有转移。归还图书借出的书回到可借状态。兑换礼品积分减少礼品库存减少。注意到没有买书被拆成了销售出库和收款结算两个事件而不是合并成一个订单完成字段。这是 REA 与常规设计的第一个分水岭同一个订单里的商品可能部分付款、部分挂账、部分用积分抵扣把它们拆开后续的对账逻辑就清晰得多。3.2 资源和资源池设计资源清单在这个场景里也很清晰图书可销售数量是一个资源池借出数量是另一个资源池因为销售和借书是两个完全不同的业务动作。储值余额顾客储值账户里的可用金额是一个资源池。积分顾客的积分余额资源池。现金收银台的实收现金资源池。押金顾客借书时缴纳的押金资源池。关键点来了用户表在 REA 里并不直接放资源字段。余额、积分这些都不应该作为用户表的列而是作为独立的资源由事件来改变它的值。你可能觉得别扭用户表加个 balance 字段多方便但加了之后赠送规则、退款回滚、跨店通用这些问题全都会来咬你。把余额当资源把充值事件和消费事件当唯一的事实来源那么余额任何时候都能从事件序列推导出来永不丢失、永不脏读。3.3 代理人识别这个场景的代理人比较明确外部代理是顾客内部代理是收银员和店长。在事件表里我统一用 agent 表存储代理类型字段再区分顾客、员工。有些人可能会说员工和顾客字段类型都不一样为什么要放一张表统一放一张表的好处是任何事件都可以关联经手人和相对方两个角色审核和权限判断只需要查同一套代理人体系不需要在事件表里分别记 customer_id 和 employee_id。用一个 role_type 标记即可。当然这是数据建模层的取舍应用层的用户表和员工表依然可以各自存在它们只是代理人在不同业务视图下的投影。REA 模型不需要你删除用户表它只是告诉你业务事实应该围绕事件和代理展开而不是围绕用户实体展开。3.4 双向性和契约表达在储值业务里充值和消费之间存在明显的双向性。顾客充值 500 得 550这 550 不是一笔孤立事件它对应着未来一串可能的消费事件。REA 里把这种预期中的交换建模为经济契约。落地到表和代码需要一个 claim_group 或 contract 字段把它们串起来。我实践下来比较顺的建模方式是每个储值事件生成一个 claim_id后续每次消费事件也记录它消耗的是哪个 claim_id。这样退款的时候要退哪个储值批次、赠送金额是否要回收就有据可查而不是拍脑袋退个平均值。积分同理每一次下发积分的事件都要对应当前积分池的流入每一次消耗积分都要记录流入来源防止积分被重复消耗。3.5 库表落地参考概念模型理清了落地的表可以精简为几张create table resource ( id uuid primary key, resource_type text not null, owner_type text, owner_id uuid, current_qty numeric(12, 2) default 0, version int default 0 ); create table agent ( id uuid primary key, agent_type text not null, external_ref uuid ); create table event ( id uuid primary key, event_type text not null, agent_id uuid references agent(id), occurred_at timestamptz not null default now(), inflow_resource_id uuid references resource(id), outflow_resource_id uuid references resource(id), inflow_qty numeric(12, 2) default 0, outflow_qty numeric(12, 2) default 0, contract_id uuid );resource 表里存的是资源池当前快照event 表里存的是每次资源变动的具体流入和流出。有人会问既然事件可以推导余额resource 表里的 current_qty 是不是冗余确实冗余但这是我刻意保留的快照字段目的是给日常列表查询加速。写入的时候用事务同时更新 event 和 resource 的 current_qty配合 version 字段做乐观锁并发问题可以控制住。如果对一致性要求更严可以把 current_qty 完全去掉每次都从 event 聚合但大多数业务系统的读压力撑不住这么搞。一条比较典型的销售查询是这样算某个顾客的当前储值余额把该顾客参与的所有储值事件里的流入金额相加扣掉所有消费事件里从储值 claim 抵扣的流出金额。如果充值送了赠送金就再按 claim 批次做加权。逻辑不复杂关键是数据来源只有一个 event 表怎么查都不会对不上。4. rea和领域驱动开发之间的连接很多团队现在都在用领域驱动设计也就是 DDD 那套聚合、实体、值对象的概念。REA 和 DDD 之间有天然的衔接点但也有一个必须想清楚的差异。4.1 聚合怎么划分DDD 里的聚合是保证一致性边界的一组对象。常规做法是把订单、订单行、支付单放进同一个聚合用订单做聚合根。放到 REA 的视角下这个聚合其实跨越了多个事件订单头可以看成一组经济契约订单行对应销售事件支付单对应收款事件。设计良好的 REA 模型会把它们映射成聚合内的不同实体而不是一张大订单表加一堆状态位。我最近的一个后台订单系统就是这么调整的把订单这个业务对象弱化为一个查询视图真正的数据结构由销售事件、收款事件、履约事件组成。订单号只是把这些事件串起来的一个业务跟踪号。改动之后订单状态机的复杂度直接下降因为不再需要维护待支付、已支付、待发货、已完成这么多状态排列组合状态只是事件推进后的一种派生结果。4.2 状态不是事件这里要特别强调一个容易踩的概念陷阱。REA 模型里的事件必须是已经发生的经济活动事实不能用事件表来保存业务对象状态。比如订单状态变为已发货这不是 REA 事件货物交给物流公司才是事件。前者是主观的状态标记后者是客观发生的资源转移。我在代码评审时经常看到有人把 event_type 写成 order_status_changed、user_status_updated 这类名字这就是典型的把系统状态机套进了 REA 的外壳本质上还是传统的状态字段只是换了个马甲。判断标准只有一个这个事件是否导致了某个资源池数量的增加或减少如果没有它就不是经济事件不应该进入 REA 的核心事件表最多放进操作日志表。4.3 和事件溯源的区别与配合有人会把 REA 和事件溯源Event Sourcing划等号因为它们都强调事件是事实来源。它们确实共享哲学前提但抽象层级不同。事件溯源是基础设施层面的做法把聚合的每一次状态变更都持久化为事件回放事件可以重建任意历史状态。REA 更接近分析模型层它定义了什么算业务事实、事实与事实之间如何关联。实际项目可以两者配合也可以只用 REA 不用事件溯源。如果团队基础薄弱我不建议立刻上全套事件溯源框架先保证核心事件表结构正确用传统的事务和快照字段过渡性价比更高。等系统复杂度真的起来了再考虑把 event 表升级为不可变的事件流引入消息总线做最终一致过渡路径很平滑因为底层的 REA 结构不需要推翻。4.4 最终一致性的处理思路储值和消费天生不是同一个时刻发生的所以 REA 系统天然适合最终一致性架构。顾客充值事件先到账消费事件后发生中间怎么保证余额不超扣我在事件写入时用资源池的 version 做乐观锁扣减之前先检查流入总量是否大于等于流出总量。分布式的极端情况下会短暂出现余额和实际事件不一致的窗口对账任务每隔五分钟扫一次事件表把所有 resource 的快照和事件聚合结果做比对不一致就告警。这个方案我在模拟环境压测过单资源池的并发写入控制在 80 笔每秒时错误率低于十万分之一。真实业务场景里大部分订单系统根本到不了这个量级所以不必担心 REA 的性能问题。5. 我在落地过程中踩过的坑模型看着清爽落地又是另一回事。整理几个我实际踩过、也帮别人排查过的坑按踩中频率排序。5.1 把系统操作当成业务事件最常见的问题就是事件表里混进了 create_order、click_button、refresh_page 这类操作记录。一旦混进去事件表的纯粹性就被破坏后续做余额推导、对账、审计全都失去可靠性。我的纠正办法是给事件表加一个严格约束插入新事件之前必须同时指明一个或多个资源的流入或流出数量否则不允许落库。这条约束可以直接用数据库触发器实现也可以放在应用层但一定要有。5.2 双向性缺失导致余额对不上有一个真实案例某同事在做会员积分的系统时只在用户消费后给积分没有在兑换礼品时扣减积分结果积分越积越多年底活动一开启低估了兑换量。这就是双向性缺失的典型表现。每一笔流入都必须有对应的流出事件或者明确的契约承诺。建模时如果发现某个资源池只进不出、或者只出不进先不要高兴大概率是模型漏了另一半而不是业务真的单向流转。5.3 一上来就追求完美陷入建模洁癖REA 框架的理论完备性很强导致很多人在建模阶段反复纠结某件事算资源还是算事件、某两个事件是不是算双向。我见过有人为一个小众业务模型开了 20 多张表结果开发进度被拖累。我的经验是第一版先覆盖核心资源池和核心事件存量和快照字段该留就留达不到理论最优没关系。模型跑起来之后根据瓶颈迭代重构比一开始闭门造车靠谱得多。5.4 与现有会计系统硬共存REA 模型最终要和财务系统对接这里有个现实问题很多公司已经有一套成熟的科目表记账系统新业务系统如果强行不生成会计凭证财务那边就不认账。我的做法是保留一个凭证生成器作为事件表的副产品每个经济事件按规则映射到会计分录。这不是 REA 的退化恰恰说明 REA 的事件比会计分录更高一层可以向下兼容。实际处理时只要保证事件表与凭证表之间通过 event_id 严格关联两边就不会对不上账。问题现象根本原因排查与处理余额莫名变负消费事件流出大于流入检查是否漏建充值事件或重复扣减积分重复使用没有记录 claim 来源引入 contract_id 串联积分下发票退款金额不对赠送金和本金混在一起按 claim 批次分别记录优惠金额报表数据与账面不符事件表混入系统操作强制事件必须关联资源流入流出回滚数据困难直接修改事件表禁止 update采用反冲新事件这张表我贴在团队文档里当速查手册用每次排查问题都能直接对上号。6. 我个人在实际操作中的体会如果您手头正打算设计一套涉及订单、库存、账户余额的系统我建议不管用不用 REA都先花半天时间把事件清单列出来。很多时候业务说不清规则就是因为没有把事件概念立起来。REA 给我的最大收获不是某个具体表结构而是强迫我养成了一个习惯每次接到新需求先问它改变了什么资源、涉及哪个代理人、和之前的事件是什么关系而不是条件反射地去加字段、加状态。最后再分享一个小技巧事件表的事务写入顺序很影响并发表现。我习惯先插入 event 表再更新 resource 快照因为事件表是 append-only插入操作几乎永远没有锁冲突而 resource 表有版本控制放在后面处理可以缩短锁持有时间。这个顺序看起来无关紧要在促销高峰期能明显减少死锁和重试次数。REA 模型的价值往往就体现在这些细节里。后续如果大家对某一块的建模细节感兴趣可以沿着事件溯源或者领域事件的方向继续展开。