1. 让我开始折腾reaREA模型的真实起因1.1 页面一打开三套数字各说各话我维护的模拟项目X是个很常见的交易系统用户在商城下单、支付、发货、退货背后牵扯订单、库存、账户余额。听起来不难但一到对账就头疼。运营看后台订单数是1421财务说收入是843笔仓库说发货数是836单三方数字永远对不上。查了半天最后往往是谁都没错只是各自从不同表里数了一个“订单”口径不一样。真正让我下决心换建模思路的是一次线上事故。用户支付成功了账户余额也扣了但订单状态卡在“待支付”因为支付回调更新状态的那行 SQL 被别的请求锁住更新失败后没有补偿。表面看是事务边界没处理好往深了想是建模出了问题大家都把订单、支付、库存当成互相独立的实体靠一堆状态字段和外部回调硬串起来状态一多谁也说不清“到底发生了什么”。这时候我重新翻出之前看到过的 rea 建模思路。rea 的全称是 Resource-Event-Agent也就是资源、事件、参与者。它不要求你设计几百张表而是要求你先回答三个问题业务里哪些东西是资源哪些动作是事件谁在参与这个事件当我把模拟项目X的订单模块用这个框架重新梳理了一遍之后很多让团队争论好几个小时的边界问题突然就变得清楚了。1.2 先给三要素一个通俗解释说人话版本是这样的。资源Resource是业务里被生产、消耗、交换、转移的有价值的东西。它不一定是实物订单里的商品库存是资源账户里的余额是资源优惠券是资源连一次上门服务时长都可以是资源。判断标准很简单它会不会因为某件业务动作而增加、减少或转移会它就是资源。事件Event是让资源发生变化的那一 “下”。资源自己不会变必须有一个业务动作触发它。支付事件让用户账户余额减少、商家账户余额增加发货事件让仓库库存减少、客户在途资源增加退货事件让库存增加、账户余额减少。事件是唯一能修改资源数量和归属的东西它带着时间戳、操作者、业务原因天然形成一条审计链。参与者Agent是发起事件或者事件指向的人、部门、系统。用户是参与者客服是参与者仓库系统也是参与者。参与者与资源的关系不是“拥有”这么简单而是“操作资源的主体”和“资源流向的对象”。一笔交易里买方和卖方都是参与者但角色不同。用看电影来类比资源是画面里的景物事件是一个镜头发生了什么参与者是镜头里的演员。REA 模型要求你始终用这样的镜头去描述业务而不是一上来就画订单表、订单明细表然后加一堆状态字段。状态字段描述的是“结果”REA 描述的是“过程”而结果往往能从过程里随时算出来。2. 用一个最普通的卖货场景一步步推演出完整模型2.1 先理清钱和货的流向而不是先建表我个人的习惯是拿到一个业务需求先不要打开数据库设计工具也不要写建表 SQL先找一块白板画一条时间线从用户开始浏览到最终结束经过了哪些业务动作每个动作让哪些东西增加了哪些东西减少了。模拟项目X里最普通的场景是用户用账户余额购买一件实物商品。顺着时间线拆会得到几个连续的片段用户选择商品并提交订单系统为这笔交易保留库存。用户发起支付账户余额减少商家的应收或现金资源增加。仓库拣货并出库库存资源减少包裹资源增加。物流送达用户在系统确认收货包裹资源转移到用户名下。用户申请退货仓库收货后库存增加账户余额减少。这些片段就是事件。每个片段前后资源的总量并没有凭空多出来只是从一个人手里流到另一个人手里或者从一种形态变成另一种形态。REA 的核心直觉就在这里业务不是一堆静止的实体而是一系列让资源转移的事件流。2.2 五个关键事件与资源增减明细为了验证模型我把上面的场景整理成一张表每个事件里记录“资源从哪来、到哪去、增减多少、谁是操作者”。这张表后来几乎成了整个订单模块的设计底稿。事件资源流入资源流出参与方业务含义订单提交无实际资源增减产生承诺库存预占承诺减少用户、销售团队锁定资源等待后续事件支付成功商家应收增加用户余额减少用户、支付网关完成货币资源转移仓库发货客户在途资源增加仓库库存减少仓库系统、用户商品资源离开仓库确认收货用户资产增加客户在途资源减少用户、物流系统资源正式进入用户控制退货退款用户余额增加、库存增加商家应收减少用户、客服反向资源转移这张表看起来很直观但放到代码层面就会遇到一个经典问题一个订单可能拆成多个包裹发货也可能部分退货这时资源和事件就变成了多对多关系而不是订单主表加几个金额字段就能搞定的。2.3 为什么事件和资源之间需要一张明细表很多从传统建模转过来的人第一次看见 REA 都会问直接在事件表里加一个“资源变化”字段不行吗答案是不行。一个支付事件里用户余额减少是一个资源的变化商家应收增加是另一个资源的变化这两个变化必须作为一个事件的两个侧脸同时存在缺一个都说不清楚这笔钱去哪了。所以我在设计里会拆出两张核心表event 表记录事件本身event_entry 表记录这个事件涉及的具体资源和增减方向。一个支付事件在 event 表里只有一行但在 event_entry 表里至少有两行一行表示用户余额减少一行表示商家应收增加。这有点像会计里的复式记账每一笔业务活动都同时留下借和贷两条记录账才能永远平。用这种结构去表达“一个订单拆三包发货”也非常自然发货事件只有一条但 event_entry 里可以有三条分别指向三个不同的库存批次资源退货时也不需要删除原来的发货记录只需要新增一条负向事件把库存加回来。所有历史过程都留在表里随时可以被查询、被审计、被重算。提示如果一开始就采用这种事件明细表后续做对账和排查问题时会省掉大量“死无对证”的烦恼。事件表是业务事实状态表只是投影。3. 落到数据库与代码时的关键动作3.1 最小可用的表结构长什么样做完概念推演我把模型落成了实际的表结构。这里给出一个简化版本是模拟项目X里订单模块最初的真实骨架CREATE TABLE agent ( agent_id UUID PRIMARY KEY, agent_type VARCHAR(32) NOT NULL, -- CUSTOMER / MERCHANT / SYSTEM name VARCHAR(128) NOT NULL ); CREATE TABLE resource ( resource_id UUID PRIMARY KEY, resource_type VARCHAR(32) NOT NULL, -- INVENTORY / BALANCE / COUPON name VARCHAR(128) NOT NULL, owner_agent_id UUID REFERENCES agent(agent_id) ); CREATE TABLE event ( event_id UUID PRIMARY KEY, event_type VARCHAR(64) NOT NULL, -- PAYMENT / SHIPMENT / RETURN occurred_at TIMESTAMP NOT NULL, actor_agent_id UUID NOT NULL REFERENCES agent(agent_id), business_ref VARCHAR(128) -- 关联原始订单号等业务标识 ); CREATE TABLE event_entry ( entry_id UUID PRIMARY KEY, event_id UUID NOT NULL REFERENCES event(event_id), resource_id UUID NOT NULL REFERENCES resource(resource_id), delta NUMERIC NOT NULL, from_agent_id UUID REFERENCES agent(agent_id), to_agent_id UUID REFERENCES agent(agent_id) );event_entry 里的 delta正数代表资源流入负数代表资源流出。from_agent_id 和 to_agent_id 用来表达资源在参与者之间的转移方向。因为几乎所有查询都是通过 event_id 或 resource_id 来找明细我会给这两列都建索引否则数据量一大查询会很痛苦。这套结构里没有“订单状态”字段没有被删改过的冗余金额。订单当前是什么状态由最近一组事件的组合结果推导出来账户余额是多少由所有余额资源相关 event_entry 的 delta 之和算出来。表结构非常稳定业务规则变化时大多只需要新增事件类型而不是不停加字段。3.2 原子性、幂等性与并发扣减结构只是第一步真正让 REA 落地的是事务边界。因为一个事件必然对应多条 event_entry写数据时就必须保证“要么这个事件的所有明细都写入成功要么一条都不出现”。我把事件创建和明细写入放在同一个数据库事务里BEGIN; INSERT INTO event(event_id, event_type, occurred_at, actor_agent_id, business_ref) VALUES ($1, PAYMENT_SUCCESS, now(), $2, $3); INSERT INTO event_entry(entry_id, event_id, resource_id, delta, from_agent_id, to_agent_id) VALUES (gen_random_uuid(), $1, $4, -100, $2, $5); INSERT INTO event_entry(entry_id, event_id, resource_id, delta, from_agent_id, to_agent_id) VALUES (gen_random_uuid(), $1, $5, 100, $2, $5); UPDATE resource SET version version 1 WHERE resource_id IN ($4, $5) AND previous_version_matches; COMMIT;这里的previous_version_matches代表乐观锁判断。用户余额是资源表里的一行两个不同请求同时扣这一个资源时必须保证只有一个能提交成功。我会给 resource 表加一个 version 字段更新前比对版本号版本不一致就重试或报冲突。幂等性问题也要提前处理。支付回调由于网络原因可能重复推送如果不做幂等一个支付事件被插入两次余额就会被扣两次。我的做法是在 event 表上建一个业务幂等键比如用支付平台返回的流水号作为唯一约束插入时如果冲突就认为事件已经存在直接返回原事件不再重复执行。3.3 从事件明细还原“当前库存”和“当前余额”事件明细是事实但业务系统不能每次查余额都把整个事件表扫描一遍。我的方案是维护一组投影表也叫读模型。每次事件提交成功后在同一个事务里更新对应的汇总行或者用异步任务去刷新。逻辑不复杂-- 简单还原某个资源的当前数量 SELECT COALESCE(SUM(delta), 0) FROM event_entry WHERE resource_id $1;数据量小的时候这种实时聚合完全够用数据量大了就建一张 resource_balance 表在事件提交后同步更新。这里需要注意一点千万不要在 event_entry 上做物理删除。一旦删除历史事实就被篡改所有汇总都可能对不上。4. 预订、退货、组合商品REA 对复杂业务的扩展4.1 预订场景用承诺连接现在和未来不是所有业务动作都会立刻改变资源数量。订酒店、订共享车位、演唱会选座这些场景在“正式扣款”前的很长一段时间里资源并没有真正减少只是被“预占”了。传统表设计一般用一个 status 字段表示“已预订”但预订超过时限后释放、多人同时抢同一个资源这类问题容易写成一堆 if-else。REA 模型里专门有一个概念叫承诺Commitment。它描述的是“未来某个事件发生后资源会发生转移”的预期。我在模拟项目X的预约模块里加了一张 commitment 表CREATE TABLE commitment ( commitment_id UUID PRIMARY KEY, resource_id UUID NOT NULL REFERENCES resource(resource_id), future_event_type VARCHAR(64) NOT NULL, quantity NUMERIC NOT NULL, status VARCHAR(16) NOT NULL, -- ACTIVE / FULFILLED / CANCELLED expires_at TIMESTAMP, created_by UUID REFERENCES agent(agent_id) );预订动作只是写入一条 status 为 ACTIVE 的承诺并不扣减资源。等到用户真正入住、付款才生成一个正式事件把承诺标记为 FULFILLED 并同时写入资源增减明细。如果超时未履行把承诺置为 CANCELLED资源自动释放。这样改动带来的最大好处是库存查询不再只看当前数量还能看到“已被承诺但尚未消耗的数量”对超卖控制非常有效。4.2 退货与纠正用相反事件而不是删数据刚开始我的团队容易进入一个误区用户退货就想把原来的发货事件记录删掉或者给订单状态直接改回“未发货”。这在 REA 视角下是危险的因为它抹掉了历史事实。真实业务里退货不是一个“回到过去”的动作而是一个全新的、向后的资源转移事件。正确做法是新增一个 RETURN 事件它关联的 event_entry 与 SHIPMENT 事件的条目数值相反仓库库存增加用户资产减少商家的应收或退款账户发生变化。这样原始发货记录仍然存在但查询“当前库存”时正负向下的事件会被自然抵消。对账时也能清楚看到这个用户确实是 6 月 5 日买的6 月 8 日退货了而不是数据被改得看不出痕迹。唯一可以物理删除的是“尚未对外生效”的草稿型事件。比如用户下单后立即取消了支付还没发生这时撤销承诺记录或删掉待提交的事件是合理的。一旦事件已经产生资源增减、已经被下游系统消费就只允许追加新事件来纠正。4.3 组合商品与多结算工具天然支持明细分账电商里买一个手机可能附带赠品也可能用“余额 优惠券 积分”混合支付。传统表设计要么在订单上堆一堆支付字段要么单独建一张支付明细表到了对账阶段再去人工核对每笔分账。REA 处理这类场景很直接组合商品在资源侧建一个组合关系套装的每个子件都是独立资源混合支付则是一个支付事件挂多条 event_entry每条指向不同的资金资源。比如一个价值 100 元的订单用户余额扣 40优惠券资源扣 30积分资源抵 30。一个 PAYMENT 事件下就有三条明细分别对应三种资源的 delta 变化。这样后续无论财务要按余额核对还是按优惠券核销都能直接从 event_entry 里筛出来不需要再维护一套额外的对账表。5. 用了一段时间后我遇到并踩过的坑5.1 把 REA 当成 ER 图画是最大的误区有段时间团队成员以为用了 REA 就是把表名换一换。他们照样把“订单状态”塞进 event 表把“支付金额”冗余在 event 表上event_entry 里也不体现资源转移方向整张表最终退化成一个加了几个外键的传统订单表。这不是 REA这是换皮不换瓤。REA 的关键约束是事件只描述发生了什么资源增减永远走 event_entry 明细参与者通过关联表达角色而不是把所有信息都压在一行事件字段里。如果你的 event 表里有十多个业务字段而 event_entry 却存不满两三条明细就该回头审视到底有没有按资源流的思路建模。5.2 事件粒度太细系统维护成本直线上升这是另一个方向上的坑。有同事为了“完整记录一切”把用户点击按钮、前端请求到达、队列入队都定义成事件。结果事件表一天几百万行真正有业务意义的却不多查询变慢排查问题时反而被淹没在噪声里。我的建议是事件粒度只划到“对业务资源产生了实际影响或者需要参与多方对账”的层级。支付成功是一个事件支付请求发起到第三方平台不是一个事件出库完成是一个事件仓库内部那几步履历没有必要全部进事件表。细粒度日志让日志系统去管REA 事件专门承载业务资源变化。5.3 不是所有场景都适合 REA我的选型判断REA 很好但对纯管理类、配置类的模块就是杀鸡用牛刀。比如后台维护一张商品分类表或者保存用户收货地址这些数据没有资源转移语义强行套 REA 只会让简单查询变得绕。我给自己定了一个选型标准这半年基本没踩过偏场景特征适合模型原因资源会流转、消耗、转移多参与方REA能完整记录资源流并支持对账状态多、操作频繁、需要审计REA事件即事实历史不可篡改简单增删改查无状态机传统 ER / CRUD没必要引入事件和明细的复杂度配置类、一次性写入传统表结构过度设计会成为负担如果你是第一次尝试不要一上来就把整个系统重构。挑一个交易链路最重的模块比如订单和库存先跑通 REA 那两张核心表再决定要不要继续铺开。6. 顺带解锁的技能审计、聚合边界与一套查询源6.1 每条记录都能回答“当时发生了什么”自从切入 REA客服和财务来找我查数据时我不再需要去翻日志、反推状态更新时间。一条 event 记录天然包含了事件类型、发生时间、操作者、关联业务单号一条 event_entry 记录包含了资源增减、来源主体、去向主体。几乎任何一笔资源变动都能在五秒内回答五个问题谁、什么时间、做了什么、哪类资源变化了多少、资金从哪到哪。这在处理用户投诉和平台合规审计时价值非常大。传统表设计里“为什么这笔订单当时扣了这笔金额”往往只能靠猜而在 REA 模型里这就是一次查询的事。6.2 用 REA 反推聚合边界帮 DDD 落地我这几年也尝试按领域驱动设计来组织代码但最头疼的问题一直是聚合边界划在哪。Credit 到底属于订单聚合还是用户账户聚合同一个支付请求要不要锁账单REA 给了我很自然的答案一个事件所涉及到的资源和参与者就是最合理的聚合边界。支付事件会同时接触用户余额资源、商家应收资源、订单关联编号那这三个资源就应该由同一个聚合来保证一致性。发货事件只涉及仓库库存和包裹资源那它就是另一个聚合。这样划分之后跨聚合的一致性需求变得极少代码里到处都是事务的情况也少了因为资源变更通过事件落库天然被收拢到了一起。6.3 所有报表终于共用一个查询源最直接的收益还是报表口径统一。以前订单报表、财务流水、库存报表各查各的表现在它们都是从事件表加明细表派生的投影只是按不同维度做聚合-- 按资源类型聚合得出每日库存变化 SELECT resource_id, DATE_TRUNC(day, occurred_at) AS day, SUM(delta) AS delta FROM event_entry e JOIN event ev ON e.event_id ev.event_id GROUP BY resource_id, DATE_TRUNC(day, occurred_at); -- 按资源汇总当前余额 SELECT resource_id, SUM(delta) AS balance FROM event_entry GROUP BY resource_id;基本报表需求都能用同一套数据源覆盖。更重要的是当有人质疑报表数字不对时都可以拿出一条具体的事件明细来验证而不是两边各拿一张汇总表比来比去。我后来在模拟项目X里做日终对账耗时从原来的两小时降到了十几分钟做的主要优化就是把对账逻辑直接从 event_entry 上计算绕开了一堆中间汇总表。如果让我重新选择一次我不会在所有模块都机械套用 REA但我会在每一条交易链路的白板上先试着画出资源、事件、参与者。画得出来说明这个模块有做账务级建模的价值画不出来再退回传统的表设计。这套思路帮我把之前纠缠不清的订单、库存、账户梳理成了干净的时间线也让团队在讨论需求时有了共同语言我们不是在争论字段叫什么而是在争论哪件业务事件先发生、哪个资源先变化。