一文搞懂REA模型：资源、事件与参与者的业务建模之道

朋友发消息问我“你听说‘rea’没有”我第一反应是某个新框架后来他发来一张模型图我才意识到他说的是 REA——Resource-Event-Agent资源-事件-参与者模型。这玩意在会计信息系统和企业建模领域存在了快四十年最近这两年又被人翻出来因为搞微服务、搞DDD、搞数据中台的人发现用 REA 来梳理核心业务意外地好用。简单说REA 是一种建模方式它把业务世界里的东西分成三类资源Resource、事件Event、参与者Agent。资源是经济价值载体比如商品、现金、积分事件是资源发生变化的行为比如销售、收款、出库参与者是发起或参与事件的人或组织比如客户、门店、仓库管理员。这套模型能解决的问题很实在账对不齐、库存漂移、业务状态满天飞、流程走一半数据就乱了。适合后端开发、架构师、产品经理尤其是做交易、库存、账务系统的朋友。下面我把 REA 的底层逻辑、建模方法、落地步骤、踩坑经验一次性说清楚。1. 为什么需要 REA传统业务建模的三大硬伤1.1 你每天在维护的状态其实一直在掩盖问题大多数业务系统落地时第一反应是建表。商品表、订单表、库存表、流水表每个表里塞几个状态字段。订单表里有待支付已支付已发货已完成库存表里有现有量可用量冻结量对账的时候靠这些状态字段去猜业务到底进行到哪一步。我见过太多项目改不动、对不上账根子就在这系统保存的是结果不是原因。你只知道库存表里剩余数量是 50但不知道这 50 是怎么来的——是入库了 100 后来卖了 50还是入库了 80 后来退了 30如果直接改状态数据审计无从谈起出问题只能干瞪眼。1.2 复式记账很伟大但它只活在财务软件里财务系统用借贷记账法每一笔经济业务记两笔账有借必有贷借贷必相等。这解决了钱去哪了的问题但问题在于业务系统的开发人员普遍不熟悉借贷设计数据库的时候不会套用复式记账的思路于是业务库和财务库长期是两张皮。数据先落到业务表再手工或定时任务转到财务系统中间对不上就产生一堆差异表。REA 的出身恰恰是会计信息系统研究它把复式记账提升成了更适合信息系统建模的范式不再强调借和贷两个账户维度而是用事件作为业务的核心把资源的流入流出、参与者的交互用统一的方式表达。实际上你记住一句话就能切入 REA业务系统真正该存储的是事件本身而不是事件造成的影响。1.3 一个例子传统订单表到底哪里别扭假设有个电商小程序用户下单买一个杯子。传统做法是订单表加一条记录状态待支付库存表减少一个可用数量用户表加一个积分变动记录这三张表由三个服务去更新靠分布式事务或消息队列硬凑一致性。一旦某个环节失败要么订单扣库存不一致要么积分发重排查起来非常痛苦。用 REA 的视角看下单这个事件包含三个视角资源是杯子和钱事件是销售订单确认参与者是用户和平台。你要做的是把一次交易产生哪些资源变动记录下来后续的库存多少、账户余额多少、毛利多少都是从这个事件流算出来的。理解了这一点REA 的建模就有了方向尽量不依赖冗余的状态字段而是从事件历史推导业务现状。这在架构上叫事件溯源在会计上叫流水账在业务上叫可追溯。REA 就是这三者的统一抽象。2. REA 的三个核心元素与两种关键关系2.1 资源Resource被管理的价值载体资源是业务里被操作、被交换、被消耗的对象特性是可以被计量、有经济意义。商品是资源现金是资源积分是资源库房空间、工时也可以被看作资源。资源不一定是实物服务时长营销预算都可以建模为资源。资源的属性通常有时间维度和数量维度比如库存盘点时点的数量某笔交易涉及的金额。REA 特别强调一点资源不应该直接存一个当前状态而是记录资源的可得历史通过事件推导当前状态。2.2 事件Event系统最核心的一等公民事件是 REA 的灵魂。它表示在某个时间点某种资源发生了增加或减少且有明确的参与者。比如用户支付了 50 元仓库发出了一个杯子用户退还了杯子。事件必须有时间戳、有方向流入还是流出、有数量、有关联资源、有关联参与者。识别事件是 REA 建模最关键的步骤。我的经验是看两个特征事件对应的是变化本身不是变化后的结果。比如订单状态变为已支付不是事件收到一笔支付款才是事件。事件必须有实际业务文件支撑比如订单号、支付流水号、出库单号。这些单据就是事件的证据。2.3 参与者Agent谁动了这些资源参与者和事件关联表示谁参与了这笔业务。参与者可以是个人、组织、系统角色。常见的情况是内部参与者销售员、仓管员和外部参与者客户、供应商。参与者角色的引入让 REA 模型天然能回答这件事是谁做的这种审计问题。这也是很多常规表结构做不到的订单表里通常只有一个用户 ID但谁审核了这笔订单谁最终确认了发货往往被我扔在操作日志里查起来非常痛苦。2.4 两两关系入/出、互换、控制REA 定义了资源、事件、参与者之间的三种基本关系资源-事件关系存量与流量事件使资源增加或减少叫 inflow 或 outflow。一个事件至少涉及一个资源流入或流出。事件-事件关系互换典型的是销售和收款一笔销售事件对应一笔现金流入事件。不是每笔业务都需要配对但涉及交换的业务一定有这种成对关系。事件-参与者关系控制参与者参与事件负责发起、执行或接收。一个事件至少有一个内部参与者通常也有一个外部参与者。这三个关系就是 REA 建模的全部语法。听起来简单真上手时很容易乱尤其是把资源的变化和事件混为一谈。我见过有人把商品上架当成事件但从资源视角看上架本身没有发生经济价值的变化它只是商品这个资源的属性变化真正的资源流入事件是采购入库。3. 完整案例用 REA 给积分商城系统建模3.1 业务需求做的是一个积分商城核心业务包括用户通过签到、消费获得积分积分可以在商城兑换商品兑换后扣减积分后台可以调整积分比如人工补偿、活动赠送月底要能输出积分发放明细、消耗明细、用户余额对账单。用传统表结构设计很自然地会做一张 user_points 表存一个当前余额字段然后每次发放和扣减都 UPDATE 一下。问题在于一旦出现并发操作很头疼余额要么用乐观锁要么用悲观锁人工调整积分没有留痕月底报表不知道该信操作日志还是信余额表。3.2 识别 R/E/A把需求翻译成 REA资源积分Points、兑换商品Product、订单额度OrderQuota事件积分发放PointsGranted、积分扣减PointsRedeemed、积分调整PointsAdjusted、兑换订单创建OrderCreated、兑换订单发货OrderShipped、兑换订单完成OrderCompleted参与者用户Customer、运营人员Operator、系统System、仓储人员WarehouseStaff画出关系积分发放事件inflow 积分由用户和系统参与积分扣减事件outflow 积分由用户参与兑换订单创建事件outflow 积分预占同时 inflow 兑换商品预留商品兑换订单发货事件outflow 商品由仓储人员参与这里有个设计要点订单创建时并不马上扣减积分而是创建一条预占事件真正发货后才做最终扣减。这个预占和最终扣减就是一对承诺事件与实现事件对应 REA 里的成对事件关系。落地时可以用 status 字段区分但所有资源数量的变化都用事件记录而不是字段覆盖。3.3 表结构落地数据库设计上不用把每个事件都建一张物理表。更常见的做法是统一一张 point_events 表加一个事件类型字段去区分发放、扣减、调整。核心表结构如下-- 积分资源流水表 CREATE TABLE point_events ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL, -- 外部参与者 operator_id BIGINT, -- 内部参与者空表示系统 event_type VARCHAR(32) NOT NULL, -- GRANT/REDEEM/ADJUST/FREEZE/UNFREEZE direction TINYINT NOT NULL, -- 1 流入-1 流出 points INT NOT NULL, -- 变动数量 resource_id BIGINT NOT NULL, -- 积分账户 ID即资源实例 order_id BIGINT, -- 关联业务单据事件的证据 event_time DATETIME NOT NULL, remark VARCHAR(255) ); -- 积分账户表只存投影可由事件重算 CREATE TABLE point_accounts ( account_id BIGINT PRIMARY KEY, customer_id BIGINT NOT NULL, total_points INT NOT NULL, -- 当前余额快照 updated_event_id BIGINT NOT NULL -- 最近一次事件 ID );point_accounts 里的 total_points 不是唯一的数据源它只是一个投影。任何一笔余额想被验证都可以通过 sum(point_events.points) 重新计算。这个设计的好处是异常数据产生后不用拍脑袋改余额重新对账就能发现问题。3.4 核心代码逻辑积分发放与扣减事件回调的伪代码大致是这样// 发放积分先写事件再更新投影 Transactional public void grantPoints(Long customerId, int points, Long orderId) { PointEvent event new PointEvent(); event.setCustomerId(customerId); event.setEventType(GRANT); event.setDirection(1); event.setPoints(points); event.setOrderId(orderId); event.setEventTime(now()); pointEventRepository.insert(event); PointAccount account accountRepository.lockByCustomerId(customerId); account.setTotalPoints(account.getTotalPoints() points); account.setUpdatedEventId(event.getId()); accountRepository.update(account); } // 扣减积分校验余额写扣减事件 Transactional public boolean deductPoints(Long customerId, int points, Long orderId) { PointAccount account accountRepository.lockByCustomerId(customerId); if (account.getTotalPoints() points) { return false; } PointEvent event new PointEvent(); event.setCustomerId(customerId); event.setEventType(REDEEM); event.setDirection(-1); event.setPoints(points); event.setOrderId(orderId); event.setEventTime(now()); pointEventRepository.insert(event); account.setTotalPoints(account.getTotalPoints() - points); account.setUpdatedEventId(event.getId()); accountRepository.update(account); return true; }关键点是先写事件再更新投影。为什么不先扣余额再写流水因为事件是事实余额是结果。如果先动余额事后审计没法区分是逻辑 bug 还是并发问题先写事件的话哪怕投影更新失败也可以重放事件把余额修回来。提示余额投影表不要用 MySQL 的 AUTO_INCREMENT 做主键做并发控制要用行锁SELECT FOR UPDATE 或用版本号保证同一账户并发扣减时不会超扣。否则事件是对的投影也照样会漂。4. REA 如何秒杀库存与账务的历史遗留问题4.1 库存系统从减库存到记出库事件库存系统是 REA 体现价值最明显的地方。传统做法是 orders 表减库存退款单表加库存库存表总有个 available_stock 字段两份单据同时改它冲突和抖动是家常便饭。REA 的做法是任何库存变动都必须对应一个入库事件或出库事件。采购入库、销售出库、退货入库、盘点调整、报废出库每类事件都有独立的业务编号。库存表只做全量重算的视图或投影汇总SELECT warehouse_id, product_id, SUM(CASE WHEN event_type IN (PURCHASE_IN, RETURN_IN, ADJUST_IN) THEN quantity ELSE 0 END) AS total_in, SUM(CASE WHEN event_type IN (SALE_OUT, SCRAP_OUT, ADJUST_OUT) THEN quantity ELSE 0 END) AS total_out FROM inventory_events GROUP BY warehouse_id, product_id每一条库存流水都能回答什么时候、哪个仓库、谁操作的、为什么变动这四个问题。做库存对账时不再依赖两个系统之间靠 Excel 转来转去而是让两套系统都输出事件流然后做流与流之间的比对。4.2 财务对账用成对事件自动找平做交易系统的人都知道最怕的就是渠道账单和业务账单对不上。传统做法是业务系统导出一张交易明细表渠道系统导出一张账单明细表两边按订单号匹配匹配不上的进异常池。REA 的成对事件思想在这里能直接派上用场。渠道支付成功是一个资金流入事件业务系统订单确认是另一个资源流出事件。把两边的事件都落库比对的就是同一笔业务对应的事件对是否完整。举例订单 A 应该有一条产品销售事件和一条渠道收款事件两事件通过关联键order_id、payment_no关联。如果只有销售事件没有收款事件就是应收未收只有收款事件没有销售事件就是多收等待退款。这比直接比对金额字段更可靠因为事件本身携带了业务语义而金额字段只是数字。4.3 审计视角每个事实都不可丢REA 模型天然支持审计追踪因为所有变更都是追加式的事件记录不是覆盖式更新。这让系统在面对为什么这笔数据变成这样时可以直接回放发生过的所有事件找到问题源头。我实际做过的项目中有一个用户投诉积分被莫名扣减。传统表结构只能看到当前余额减少了查不到是谁扣的。改造后通过 point_events 表按用户维度查询立刻看到某条 ADJUST 事件操作者是某运营账号时间是某天某时备注是活动补偿修正。问题当场定位用户也信服。这就是 REA 的隐性价值它不直接创造业务功能但它让责任变得可见让数据经得起追问。5. 常见问题与落地心得5.1 实践中的典型翻车现场我整理了一张问题速查表都是初次落地 REA 时容易踩的坑典型表现根本原因解决思路事件表和业务单据表重复不知道该写哪张把业务单据和事件当成两回事业务单据是证据事件是证据在模型中的投影。先有单据再生成事件事件反查单据事件识别不出来画图画了半天全是资源混淆了对象和对象的变化问自己这个业务动作是否让资源增加或减少没有增量的动作不配叫事件事件数量爆炸表膨胀得厉害把高频查询结果也设计成事件只记录经济增量类事件查询条件变化本身不该入事件流用普通索引或日志解决账号余额对不上事件流是准的投影表是错的只做了事件落库投影更新没做幂等或事务处理投影必须在事件事务内同步更新并用事件 ID 做幂等存模型的代码层成了面条代码判断逻辑散落没有把 REA 的成对事件语义固化进领域层在领域服务里统一封装事件创建和关系关联不要让每个接口自己拼事件5.2 实操心得一先画 REA 图再建库表我强烈建议动手写建表 SQL 前先在白板上把所有核心业务动作按 R/E/A 画一遍。画图过程中你会发现很多原来差不多的概念其实边界模糊比如退款它是销售事件的取消还是一个新的资源流出事件不同业务定义会导向完全不同的表结构。我的选择是退款单独建模为一类事件并和原销售事件通过 refund_order_id 关联。因为退款有自己的凭证、有独立的审批流、有复杂的金额计算硬要把两件事冲掉会让历史信息丢失。宁可事件粒度细一点也不要为了减少记录数而合并事实。5.3 实操心得二不是所有项目都值得上 REA坦白讲REA 不是银弹。如果你做的系统是简单 CRUD、不需要审计、不需要多方对账、业务动作几乎没有资源增减硬套 REA 只会让代码更绕。比如一个内容管理后台文章只是增删改查就不需要拆成资源事件参与者。我的判断标准就三条是否有明确的经济价值流转钱、货、积分、点数是否需要回答某时间点为什么是这个数据是否有多个系统、多个角色对同一资源进行操作三条里命中两条REA 就是值得投入的建模方向一条都没命中老老实实建业务表更高效。5.4 实操心得三事件 ID 和业务单号必须分离做事件流设计时一定要区分业务单号和事件 ID。业务单号可能有重试、有作废、有合并比如一个支付单可能对应多笔收款事件。如果把业务单号当主键后续扩展会非常痛苦。事件 ID 必须是独立的雪花 ID业务单号只是事件里的一个关联属性。我第一次做积分系统时偷懒直接用 order_id 当事件主键后来同一个订单因为退款产生二次扣减时直接主键冲突只能做数据迁移。现在所有事件表一律用自增或雪花 ID 做主键业务单号走普通索引再也没出过这种问题。最后再分享一个小体会REA 模型第一次接触会觉得抽象但一旦你顺着资源-事件-参与者的视角重新看一遍现有系统的核心表会有种豁然开朗的感觉。库存、余额、积分这些状态类数据全部变成派生数据后系统的扩展性和可排查性都会明显上一个台阶。如果团队里有人正在为账目对不上发愁可以试试用 REA 把核心交易链路重新梳理一遍哪怕不重构代码光是画几张模型图也足够帮你发现不少隐藏的设计问题。