我在某互联网公司做后台开发时接手过一个内部代号叫rea的项目。起因很朴素公司自研的电商后台订单、库存、资金三个模块的数据总是对不齐。订单显示已发货仓库说没出库财务说收到钱订单却查不到流水运营导出一份销售报表跟业务系统的数字差了一百多件。业务方每天在群里发截图研发只能靠临时脚本去修数据。排查到最后问题根源不在某个接口而在整个系统的建模方式——大家都在用单据状态的方式描述业务状态字段越加越多最后谁也说不清一笔订单到底经历了什么。正当我准备继续打补丁时一位前同事提到为什么不试试REA模型。我花两个晚上把Resources-Events-Agents这套概念啃了一遍又用一个月在项目里做了最小化落地验证效果比预期好不少。这篇文章就是把那段经历完整记录下来包括建模思路、表结构设计、查询实施、以及只有写代码时才会踩到的坑。适合被状态字段折磨的后端开发、正在做业务数据建模的架构师以及想理解事件驱动建模但不想啃论文的人。1. 为什么传统的单据状态建模会越改越烂1.1 状态字段的本质是结果的快照不是事实的记录绝大多数业务系统一开始都是这样建表的订单表里有order_status库存表里有stock_quantity账户表里有balance。字段一多问题就来了。订单状态从待支付变成已支付系统只是把一个字符串改了。可这个状态对应的资金流向、支付渠道回调、库存预占、发货单生成全部散落在各个模块的日志和流水表里。一旦中间某个环节失败或者被人工干预状态字段就和真实业务脱节了。这时候你查数据库看到的只是系统认为的状态而不是实际发生过的业务轨迹。我在项目里遇到的最典型问题是发货环节。订单系统把状态改为已发货但仓储系统没有生成出库记录。两个系统各写各的状态不一致然后就有了补偿任务——定时扫描状态和流水不匹配的订单强行纠偏。纠偏脚本越写越复杂逻辑越堆越绕最终变成只有原作者敢碰的代码。1.2 两张表解决不了的库存问题库存模块更典型。传统设计通常是inventory表保存当前库存数每次出库就在字段上做减法。看似简单但一旦并发上来、退单进来、调拨发生光靠一个数字根本说不清这批货到底是哪次出库消耗的、哪次入库增加的。某次盘点实际库存比系统少127件。查来查去发现是订单取消后退货入仓但库存字段只在订单完成路径上做过回加取消路径漏掉了。这种问题的共性原因你在记录状态而不是记录事件。状态是单点的、可覆盖的事件是流式的、不可丢弃的。当业务复杂度超过一定阈值单点状态模型必然要往事件模型迁移。REA模型最打动我的地方就是它不记录结果只记录谁在什么时候对什么资源做了什么。这正是一个业务系统本该有的样子。2. REA的三个核心概念资源、事件、参与者到底在说什么REA是三个英文单词的首字母Resources资源、Events事件、Agents参与者。它最早是会计信息系统领域提出来的一个本体模型目的是让计算机能够理解经济活动的语义而不是像复式记账那样只记借贷数字。我之前总觉得这是学院派的东西等真的用它去建模一个订单流程时才发现这套概念的划分精度刚刚好。2.1 资源从商品到可追溯的经济价值资源就是一切有价值、可以在业务中流动的东西。商品是资源现金是资源仓储空间是资源一次服务也可以算资源。它不一定是物理的关键是有价值和可流动。建模时要把握一个原则资源只描述它是什么不描述它当前还剩多少。库存数量不是资源的一个属性而是资源相关事件的统计结果。比如商品A的库存剩余应当由入库事件的总量 - 出库事件的总量推导出来。这个思路刚上手时会觉得绕但它能天然避免一类bug多个业务同时修改库存字段导致互相覆盖。你不修改数字你只是新增一条事件记录后续统计永远从事件流中计算。坏处是需要做一定的查询优化后面我会详细说。2.2 事件记录发生了什么而不是记录什么结果事件是REA模型的核心它的定义是一次让资源发生数量或归属变化的活动。卖出一件商品是事件收到一笔打款是事件仓库完成一次盘点也是事件。事件有几个关键特征不可变。已经发生的事件不应该被修改只能被另一个事件纠正或对冲。有方向。事件必须表达资源是从谁那里流向谁。REA里常用给予-接收配对来定义方向仓库给予商品客户接收商品客户给予现金仓库接收现金。有时间。至少要有业务发生时间和数据记录时间两个维度的字段。有参与者。事件必须落到具体的人或组织上责任边界清晰。事件与事件的配对天然对应了交换语义。一笔交易不是一条记录而是至少两个事件一个资源流出事件一个资源流入事件。这种对称性在传统单据表设计里经常被简化掉。2.3 参与者的边界人、部门、系统账户参与者是资源变化的执行者或受影响者。客户、供应商、仓库管理员、财务审核员甚至自动对账的系统进程都可以作为参与者建模。设计时要注意不要把所有参与者都设计成一个角色属性。参与者在不同事件中的身份可能不同同一批货在采购入库事件里供应商是给予方仓库是接收方在订单出库事件里仓库是给予方客户是接收方。把它建模成事件的一个引用字段比在资源上挂一个当前负责人直观得多。3. 用一个下单场景演示REA落库从业务故事到表结构3.1 先讲故事再画ER图我习惯把业务场景先描述成一段谁给谁什么东西的句子再把句子翻译成增删记录。比如一个简单的订单流程可以拆成这样客户A订购了商品B这是一个订购事件参与者是客户A和订单系统涉及资源商品B。仓库将商品B出库交付给客户A这是出库事件仓库是给予方客户A是接收方。客户A支付了货款这是收款事件客户A是给予方公司账户是接收方资源是资金。每个事件至少对应一次资源数量变化而且变化的方向可以通过给予/接收来区分。如果你把一个流程从头到尾都能写成这种句式那表结构就顺理成章了。3.2 表结构设计我在最小化落地时用了四张表参与者表、资源表、事件表、事件明细表。简单的Django项目或者Spring项目都能直接套用。参与者表用于统一归集所有内部和外部参与者CREATE TABLE agents ( id BIGINT PRIMARY KEY, agent_type VARCHAR(32) NOT NULL COMMENT customer/supplier/internal_process, name VARCHAR(128) NOT NULL, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP );资源表只保存资源的基本属性和计量单位不保存数量CREATE TABLE resources ( id BIGINT PRIMARY KEY, resource_type VARCHAR(32) NOT NULL COMMENT product/cash/storage_service, name VARCHAR(128) NOT NULL, unit VARCHAR(16) NOT NULL COMMENT 件/元/小时, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP );事件表和事件明细表是核心CREATE TABLE events ( id BIGINT PRIMARY KEY, event_type VARCHAR(64) NOT NULL COMMENT order_placed/order_shipped/payment_received, business_time DATETIME NOT NULL COMMENT 业务实际发生时间, record_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 系统记录时间, payload JSON NULL COMMENT 临时字段存完整的事件上下文 ); CREATE TABLE event_line_items ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, direction VARCHAR(16) NOT NULL COMMENT give/receive/consume/produce, quantity DECIMAL(18,4) NOT NULL, unit_price DECIMAL(18,4) NULL, INDEX idx_event_resource (event_id, resource_id) );event_line_items就是REA模型里资源-事件-参与者三元关系的具体落点。一个事件可以有多个明细每个明细描述某一类资源从某个参与者流到另一个参与者或状态变化。例如出库事件明细里directiongive的agent是仓库directionreceive的agent是客户quantity是商品数量。这种设计把订单、订单明细、出库单、出库明细这些传统表全部统一成了events和event_line_items的组合。业务上复杂的订单状态在这里变成了与订单相关的事件流。3.3 查询示例库存数量怎么算库存余额不再是一个表中的字段而是查询结果。计算某商品当前可用库存只需要统计该资源相关的所有入库与出库事件明细做一次聚合SELECT SUM(CASE WHEN direction IN (produce, receive) THEN quantity WHEN direction IN (consume, give) THEN -quantity ELSE 0 END) AS current_stock FROM event_line_items WHERE resource_id 1001;这个查询在数据量大的时候性能不会太好所以实际落地我会加一张物化快照表定期聚合或者用增量缓存来兜底。但架构上有一个关键收益库存数字永远可以追溯到它产生的每一笔事件任何一次对不上的盘点都能用SQL按事件逐条核对。查询某笔订单的全部业务轨迹也变得更简单SELECT e.id, e.event_type, e.business_time, r.name AS resource_name, a.name AS agent_name, li.direction, li.quantity FROM events e JOIN event_line_items li ON e.id li.event_id JOIN resources r ON li.resource_id r.id JOIN agents a ON li.agent_id a.id WHERE e.payload - $.order_no ORD20240218001 ORDER BY e.business_time;这类查询把一个订单经历了什么完整地展现在一条结果集里比在订单状态表里翻日志字段直观得多。4. 落地时最容易踩的三个坑4.1 坑一过度抽象把所有业务都塞进REA刚理解REA时很容易兴奋觉得它可以统一一切于是想把客户CRM、审批流、问卷记录全部塞进events表。结果项目进度拖慢查询动辄连接五张表代码可读性断崖式下跌。后来我的原则是REA只用于有明确资源流动且需要严格对账的业务域比如订单、库存、资金、采购。审批流、用户配置这类不涉及资源数量变化的场景用普通业务表就够了。抽象不是越多越好抽象是哪里有痛点才用哪里。4.2 坑二事件粒度切错导致业务复盘失败事件到底该拆多细是落地中最难拿捏的。刚开始我把订单创建、库存预占、支付回调、仓库拣货全拆成独立事件。粒度太细很多事件其实是同一个业务事务的中间步骤拆开之后事务边界变得模糊一旦中途失败补偿逻辑和正常流程抢数据。后来我采用的经验是以资源实际发生物理或资金层面的变化作为事件拆分边界。库存预占不改变实际库存就不单独建事件真正把货挪出仓库才建出库事件。支付回调代表资金实际到账建收款事件。按这个标准切出来的事件数量合适业务关联清晰补偿逻辑也能聚焦到真正需要补偿的点。4.3 坑三和财务总账对接时差点被复式记账打脸REA模型的优势是记录业务语义但财务报表认的是借贷分录。系统切换到REA之后财务那边依旧需要科目余额表、需要借贷双方平衡否则无法出报表。当时的教训是REA不能直接替换财务会计模块。资产、负债、收入、费用的入账逻辑仍然需要从REA事件流里做一次投影转换生成标准的记账凭证。这个转换层可以手工实现也可以做配置化映射但必须有。否则你的系统数据很真实财务却无法使用。我们最终的方案是在事件表里增加一个是否已生成凭证的标记用一个同步任务把业务事件翻译成借贷分录。翻译规则写在独立的映射表里财务人员可以直接在后台调整不碰代码。5. 如果重新做一遍我会改进这三件事5.1 先画事件流图再画ER图第一次做REA建模时我直接上手设计表结果反复返工。后来换成先画事件流图用方框表示事件、线条表示资源流向、角标标注参与者把整个业务流程走一遍才动手写建表语句。ER图表达的是静态关系事件流图表达的是动态行为REA建模的核心是行为不是关系。这个顺序颠倒后面会多花一倍的时间。5.2 把事件设计成不可变日志而不是可更新的业务记录事件表一旦写入最好不要允许update和delete。如果写错了应该新建一个纠正事件比如库存调整盘盈3件而不是改掉原来的出库记录。这个约束能带来一个很大的好处所有审计和回溯都可以建立在对事件流的信任上。一旦允许任何人改事件对账就失去意义。我会在数据库层面做权限控制只允许insert和select不允许update和delete业务人员要纠正数据走专门的界面生成反向事件。5.3 重新看待内部项目代号rea这个项目代号rea最初只是顺手取的直到做完才意识到名字里恰好蕴含着Resources-Events-Agents这套关键思想。整个项目的代码量不大但对数据一致性的改善非常明显。上线之后订单-库存-资金对账脚本从每天十几次告警降到每周偶尔一两次纠错人力节省了大半。更重要的是新需求的建模方式变了不再讨论状态字段怎么加而是讨论新增了哪些业务事件、资源在哪个环节流动。讨论的颗粒度变了很多架构层面的问题就提前消失了。如果读者想在自己的项目里尝试这套思路建议不要一上来就重构所有模块。挑一个状态最多、对账最痛、数据量可控的模块比如库存或资金流水用REA重写一小块跑通之后再推广。模型本身没有多复杂复杂的是从旧思维模式切换到记事件不记状态的过程。这个切换一旦完成你的数据模型会变得非常耐脏、耐改也最好维护。
