做企业系统设计这些年每次和人讨论业务建模绕不开一个缩写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 ListResourceChange resourceChanges; private ListAgentRef participants; private MapString, 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事件图最后系统上线后才发现订单、库存、财务三套逻辑互相打架。如果你也想重构一套交易系统我建议先别急着拆服务拿出几个核心流程用资源和事件把链路走一遍。画完那张图很多表结构上的纠结会自然消失。