REA模型实战：用资源事件参与者重构订单库存系统-北京尧图网络

想聊一个我最近整理业务建模思路时用的工作代号rea。它不是人名也不是某个开源框架而是我从 Resource、Event、Agent 三个词里各取首字母拼出来的缩写——资源、事件、参与者。这个模型并不是新东西但在订单、库存、资金流水混在一起的业务系统里它确实帮我解决了很多实际问题。如果你也在做后端业务开发、搞数据建模或者正在考虑事件溯源和领域驱动设计的落地方式这篇内容值得花几分钟看完。我会把我实际踩过的坑、最终落地的表结构、核心代码和排查方法都写出来方便你直接参考。我最初接触到 REA是在一次重构某电商系统的库存与订单模块时。老系统的结构很典型orders、order_items、inventory、transactions 各管各的表面看单词清晰但一旦遇到退货、换货、多次付款、跨月对账多张表之间的状态同步就会让人抓狂。那时候让我意识到一个问题大多数业务系统建模的本质不是在记录“当前是什么样”而是在记录“到底发生了什么变化”。而 REA 模型恰好就是围绕后者展开的。1. 项目概述先从“发生了什么”开始建模1.1 为什么把项目代号定为 rea先说说思路转变的过程。传统表结构擅长描述静态状态例如订单表里有 status 字段库存表里有 quantity 字段资金流水表里有 amount 字段。这些字段在业务正常时没什么问题可一旦要做审计、追溯、对账就会出现大量补丁式的日志表和状态机。REA 的想法完全不同。它让你把业务场景拆成三个核心要素Resource资源业务里被交换、被消耗、被生产的对象比如商品、库存、现金、积分、优惠券额度。Event事件直接改变资源状态的动作比如销售发货导致库存减少、收款导致现金增加、采购入库导致库存增加。Agent参与者发起或参与事件的角色比如顾客、销售员、供应商、仓库管理员。这三个词拼起来的缩写就是 REA也就是我这个项目代号的由来。在实际使用里我通常还会再加一个对偶关系Duality来把事件串起来后面会详细展开。这个建模方式天然适合订单、库存、财务这类强流程系统。它最大的价值在于业务数据不再是散落多表的状态快照而是一条可以被重放和验证的事件链。它不像传统模型那样为了查一个“当前库存”必须去 update 一行数字而是可以通过累计所有库存相关事件的结果推导出当前库存。1.2 REA 和传统表模型到底差在哪做个直观的对比方便你理解选型差异。假设有一个 SKU库存单位的库存量传统做法inventory(id, sku_id, quantity, updated_at)每次出入库都直接改 quantity 字段查当前库存很高效但查不到库存变化历史因为老数据被覆盖了。很多人会再加一张 inventory_log 表来补救这本质上就是事件表只是没有把它当作核心。REA 的做法则是event(res_id, event_type, direction, quantity, occurred_at, process_id)没有 inventory 表只有一系列库存事件采购收货 100、销售发货 -50、退货入库 5。当前库存 SUM(direction × quantity)。传统模型像拍照保存的是某一瞬间的状态REA 像录像保存的是导致状态发生变化的所有动作。这个差异带来的实际收益有几点审计天然完整每个字段变化都能找到对应事件不需要额外写 changelog。业务流程好扩展新增一个业务动作只是新增一种事件类型不用改表结构。对账更简单按资源和时间段聚合事件就能核对库存、应收款、应付款。但也要说实话REA 的缺点同样明显。报表查询通常更复杂一个简单的“订单金额统计”可能要从事件表做聚合团队如果不熟悉这套思路容易把模型做得过重或过虚。所以它不是银弹而是需要根据场景选用的工具。我在后面的实操部分会说明如何在保留 REA 核心优势的同时用一些额外设计来弥补查询上的痛点。2. 核心概念拆解资源、事件、参与者、对偶关系2.1 三个基本要素怎么落地先用一个最简单的电商下单流程把三个要素映射出来。顾客在某店铺买了一件商品流程包含顾客拍下商品创建订单用微信支付收款仓库发货库存减少顾客确认收货完成后续可能退货库存增加在这个场景里商品、库存、微信余额里的钱都是Resource。顾客下单、支付成功、仓库发货、退货入库这些动作都是Event。顾客、店铺、仓库操作员、支付渠道都是Agent。我发现很多人在建模时最容易犯的错是把“订单”当成 Resource 或 Agent。从 REA 定义看订单既不是资源也不是参与者它是事件或事件的聚合描述。更严格地说下单动作本身是一个承诺Commitment它约定未来一定会发生发货事件和收款事件。如果你的系统需要精细建模可以把订单设计成 Commitment如果只是做简单的进销存把订单状态直接映射到相关事件就够了。Resource、Event、Agent 之间有三种基础关系理解它们是建模的关键关系名称含义实际例子Stock-flow事件对资源存量的增减影响发货事件让库存资源减少采购事件让库存资源增加Participation参与者与事件之间的关系顾客发起了支付事件仓管执行了发货事件Duality两个事件之间存在经济补偿关系发货事件与收款事件相互对应一进一出构成完整交易其中最重要的就是 Duality。因为业务系统最容易出现的情况是事件之间有先后、有因果如果模型里没有表达这种“一对事件互相补全交易”的关系事件就只是流水账而不是业务账。2.2 对偶关系一个销售事件要有东西“补”回来我在实际项目中一直用 event_link 来保存对偶关系。比如一笔销售订单最终有两条核心事件销售发货事件库存减少商品给到顾客。收款事件现金资源增加钱进到公司账户。这两个事件商业上互为补偿我给了你货你给了我钱。在 REA 里它们就是一对 Duality。用 event_link 表记录后未来做对账时可以直接找“发货事件 A 对应的收款事件 B”再检查金额是否相等、时间差是否合理。对偶关系支持多对多。现实业务里经常有“一笔订单分三次付款”“一次付款覆盖多个订单”的情况。用 event_link 桥表天然能表达这种关系不需要像传统表那样加很多冗余字段。2.3 新手最容易踩的建模误区我梳理一下 REA 建模时最常见的几个误区每个都是实际项目中见到或踩过的。第一个误区把所有名词都建成 Resource。比如“订单状态”不是资源“订单号”也不是资源。资源必须是可以被交换、消耗或生产的东西。状态是事件累积的结果订单号只是聚合标识。我在重构时一度把“订单头”也建模成 Resource结果订单处理逻辑和库存逻辑纠缠在一起查询又绕又慢后来拆掉才顺了。第二个误区把 Agent 单纯当成“人”。参与者也可以是系统、设备、银行卡、支付渠道甚至法律主体。比如支付事件中支付网关是一个 Agent顾客是另一个 Agent。如果 Agent 建模仅限于人退款、差错账、渠道手续费这些场景就表达不完整。第三个误区不区分库存类型。同样是“增加库存”采购入库、退货入库、盘盈入库的业务含义完全不同。REA 鼓励用 event_type 区分而不是只用一个正负 quantity 来表达。这样后续做经营分析才可以分别统计“正常销售出库”“退货入库”“报损出库”等不同口径。数量是正向存储方向由 event_type 决定而不是把数量存成负数。3. 实操用 REA 重构订单与库存模块3.1 先把业务流程拆成事件流我建议你拿到任何需求先别想数据库表先用文字把完整事件流写出来。以我当时做的某批发系统为例核心流程如下顾客提交采购订单创建订单承诺。系统冻结库存预留资源防止超卖。顾客支付货款产生“收款事件”资金资源增加。仓库出库发货产生“发货事件”库存资源减少。系统确认收货关闭订单承诺。如果退货则产生“退货入库事件”库存资源增加应退款事件生成。在这个事件流中“冻结库存”和“库存减少”是两个不同事件。前者是承诺阶段后者是履行阶段。如果建模时混在一起就没办法处理“下单未支付但库存被占”的情况。我最终的设计是订单提交成功 → 创建预留事件direction0只占数量不改变库存支付成功 → 创建收款事件发货出库 → 创建扣减事件direction-1确认收货 → 把预留事件标记为已完成退货入库 → 创建增加事件direction1上面的预留事件我用一张独立的 commitment 表来表达避免把未生效的占用数量直接写到库存事件流里。这样既保留了 REA 的优势也照顾了实际业务对“可用库存”的实时性要求。3.2 数据库表结构怎么设计以下是我最终采用的精简版建表结构可作为参考起点。项目里用的是 MySQL 8表名和字段做了适当简化但保留核心含义。CREATE TABLE res ( id BIGINT PRIMARY KEY AUTO_INCREMENT, res_code VARCHAR(64) NOT NULL COMMENT 资源编码, res_name VARCHAR(128) NOT NULL COMMENT 资源名称, unit VARCHAR(20) NOT NULL DEFAULT PCS COMMENT 计量单位, res_type TINYINT NOT NULL COMMENT 1 商品存货 2 现金 3 虚拟额度, UNIQUE KEY uk_res_code (res_code) ) COMMENT资源表; CREATE TABLE agent ( id BIGINT PRIMARY KEY AUTO_INCREMENT, agent_code VARCHAR(64) NOT NULL COMMENT 参与者编码, agent_name VARCHAR(128) NOT NULL COMMENT 参与者名称, agent_type TINYINT NOT NULL COMMENT 1 内部 2 外部 3 系统渠道, UNIQUE KEY uk_agent_code (agent_code) ) COMMENT参与者表; CREATE TABLE event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, process_id VARCHAR(64) NOT NULL COMMENT 聚合标识如订单号, res_id BIGINT NOT NULL COMMENT 受影响的资源, event_type VARCHAR(32) NOT NULL COMMENT 事件类型, direction TINYINT NOT NULL COMMENT 1 增加资源 -1 减少资源, quantity DECIMAL(18,3) NOT NULL COMMENT 数量只存正数, unit_price DECIMAL(18,4) DEFAULT NULL COMMENT 单价, occurred_at DATETIME NOT NULL COMMENT 业务发生时间, KEY idx_process (process_id), KEY idx_res_time (res_id, occurred_at) ) COMMENT事件表; CREATE TABLE event_agent ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, agent_role VARCHAR(32) NOT NULL COMMENT 事件中的角色如顾客/操作员/渠道, UNIQUE KEY uk_event_agent (event_id, agent_id, agent_role) ) COMMENT事件参与者关联表; CREATE TABLE event_link ( id BIGINT PRIMARY KEY AUTO_INCREMENT, from_event_id BIGINT NOT NULL, to_event_id BIGINT NOT NULL, link_type VARCHAR(32) NOT NULL COMMENT DUALITY / CANCEL / ADJUST, UNIQUE KEY uk_link (from_event_id, to_event_id, link_type) ) COMMENT事件对偶关联表; CREATE TABLE commitment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, process_id VARCHAR(64) NOT NULL, res_id BIGINT NOT NULL, status TINYINT NOT NULL COMMENT 0 待履行 1 已履行 2 已取消, quantity DECIMAL(18,3) NOT NULL, created_at DATETIME NOT NULL ) COMMENT承诺预留表;有一点需要特别说明event 表中的 quantity 字段我强制只存正数方向用 direction 字段表达。这样做的目的是避免查询时出现“既有正数又有负数导致 SUM 混乱”的问题。同时所有代表“减少资源”的事件类型在代码里必须保证 direction-1例如 SHIPMENT、WRITEOFF。event_agent 表是事件与参与者的多对多连接。为什么不用单个字段存 agent_id因为一个事件可能会有多个参与者。比如支付事件既有顾客也有支付渠道发货事件既有仓管也有承运商。多对多结构可以完整记录参与者在事件中的角色。3.3 核心业务逻辑实现我用 Python 伪代码做一个核心业务逻辑示例避免绑定具体框架方便你看思路。# 假设已有 db 事务上下文 # 场景创建订单并扣减库存 def create_sale_order(sku_id, customer_id, qty, unit_price, order_no): with db.transaction(): # 1. 锁定库存资源避免并发超卖 res db.select_for_update( SELECT * FROM res WHERE id %s, sku_id ) # 2. 计算可用库存 available_qty cal_available_qty(sku_id) # commitment 预留 - 已发货 if available_qty qty: raise BizException(库存不足) # 3. 创建扣减事件实际出库发货 decrease_event create_event( process_idorder_no, res_idsku_id, event_typeSHIPMENT, direction-1, quantityqty, unit_priceunit_price, occurred_atnow() ) # 4. 创建应收款事件现金资源增加 money_res get_res_by_code(CASH_ACCOUNT) increase_event create_event( process_idorder_no, res_idmoney_res.id, event_typeSALE_RECEIVABLE, direction1, quantityround(qty * unit_price, 2), unit_price1, occurred_atnow() ) # 5. 建立对偶关系 link_event(decrease_event.id, increase_event.id, DUALITY) # 6. 创建承诺预留记录订单未完成状态 create_commitment( process_idorder_no, res_idsku_id, status0, quantityqty )这里有一个重要取舍我在同一时刻创建了“扣减事件”和“应收款事件”其实是把“支付成功并出库”合并成了一个业务事务。真实场景中支付和发货往往异步发生需要分成两步操作。为了不把文章写成具体业务方案我把业务动作抽象为“确认销售并出库”你在落地时按自己的流程拆分即可。commitment 表在这里的作用是记录“订单承诺的库存数量”防止同一批库存被重复下单。可用库存的计算口径是可用库存资源当前库存事件累计值 - 未完成的承诺预留commitment例如库存资源有 100 件已有 30 件被下单但未发货可用库存就是 70 件。只有当订单完成或取消commitment 状态变为已完成或已取消这 30 件才会释放出来。这套机制替代了传统项目里的库存锁字段逻辑上更清晰。4. 数据一致性、查询报表与性能优化4.1 不超卖的库存校验怎么做REA 模型下没有一行“库存数字”可以直接 update所以高并发场景下防止超卖必须依赖数据库行锁。我前面的代码里已经使用了SELECT ... FOR UPDATE锁的是 res 表对应 SKU 的行。这样做有几个好处同一 SKU 的并发请求会排队避免事件表里出现负库存。事务结束自动释放锁不需要额外处理死锁。库存计算口径事件累计减未完成承诺始终在事务内保持一致性。如果你的库存热点非常高比如秒杀场景建议用 Redis 预扣异步事件落库的架构。事务内的 FOR UPDATE 锁并发能力有限但胜在可靠。我看到很多项目把“库存扣减”和“事件记录”分在两个系统里最后对账对不上反而得不偿失。对于大多数中小规模业务数据库行锁已经足够。4.2 事件流做报表查询很多人说 REA 不好做报表实际情况确实比传统模型绕一点但有成熟的解决方案。核心思路是日常查询和报表查询分离。日常查询走聚合根和星型模型。以订单模块为例我把订单号作为 process_id 存入事件表查询一个订单的全部业务动作时直接WHERE process_id ?按时间排序即可。事件表按 process_id 建索引单笔订单查询速度很快。报表查询则走定时聚合表。比如统计每月的 SKU 出库量直接扫事件表在数据量大时不现实所以我建议维护一张日快照表CREATE TABLE daily_stock_snapshot ( biz_date DATE NOT NULL, res_id BIGINT NOT NULL, open_qty DECIMAL(18,3) NOT NULL, in_qty DECIMAL(18,3) NOT NULL, out_qty DECIMAL(18,3) NOT NULL, close_qty DECIMAL(18,3) NOT NULL, PRIMARY KEY (biz_date, res_id) );每天凌晨跑一个定时任务把前一天所有库存事件聚合进快照表。查询月报时只需要把一个月内每一天的快照汇总性能远好于扫描全量事件表。在这里需要特别强调快照表只是查询加速不是数据源一旦发现快照数据异常仍然要从事件表重新聚合修正。4.3 对账脚本机制REA 带来的一个额外红利是对账特别自然。我不需要看“系统库存字段”和“实物库存”是否一致而是直接重放事件流让系统自己算一遍账。对账脚本的重点就两步遍历指定时间范围内的所有事件按资源和 event_type 聚合数量。把聚合结果与库存台账、财务应收款余额做核对。差异一出现基本就能定位到具体事件因为每条账目都有确切的发生时间、参与者、关联订单。我之前在处理长期不平的库存时传统模型需要人工翻日志而 REA 模型下直接查出问题事件半天内就能修复。还有一些常见的不一致来源扣减事件和承诺预留没有同时提交、重复创建了支付事件、退货入库回填错了资源编码。这些问题在对账脚本里都可以通过“事件完整性校验”发现例如检查同一 process_id 下是否存在没有 Duality 对应的孤独事件检查扣减事件总量是否超过资源入库总量等。5. 常见问题与排查技巧实录我在实际项目里整理了下面这些问题虽然针对的是订单库存场景但思路是通用的。问题原因解决方式并发下出现负库存没有对资源行加锁校验和扣减不在同一事务用 SELECT FOR UPDATE 锁资源行关键逻辑放在同一事务报表统计不准确直接把数量存成负数SUM 时正负混淆数量统一存正数使用 direction 字段表达增减方向订单流程无法追溯事件之间没有关联不知道哪个发货对应哪个收款引入 process_id 聚合标识和 event_link 表库存预留释放不及时订单取消时没有更新 commitment 状态在订单状态机里同步处理 commitment 的完成/取消性能下降报表直接扫描事件全表设计日快照表定时聚合查询与事件主库分离对账不平多个系统各自扣库存没有统一事件源以事件中心作为唯一数据源所有库存变化都写事件表说一下我自己踩过的坑。早期建模时我把“订单”本身当成了一个资源结果订单查询、订单状态更新、订单金额统计全部要经过资源表逻辑变得极其别扭。后来参考 REA 社区的做法把订单抽象为 Commitment 和一系列事件的聚合过程代码反而简单了。还有一个常见坑是事件类型命名不规范。比如既用 SALE 又用 SALES既用 SHIPMENT 又用 OUT_STOCK导致统计脚本写了一堆兼容逻辑。建议在项目一开始就维护一个事件类型字典作为核心配置纳入代码评审范围。如果你也想在自己的项目里试这套方案我的建议是从一个边界清晰的模块开始比如只做“销售出库收款”这条链路不要一上来就把采购、生产、库存全量改造。先用一个业务场景跑通 REA 的表结构、事件流和对账机制团队认可之后再逐步扩大范围。这套模型虽然上手有点门槛但它把业务规则从数据存储里解耦出来的思路会在后续的每一次需求变更中给你回报。

REA模型实战：用资源事件参与者重构订单库存系统

相关推荐

再也不怕装不上：图形化一键安装器背后的原理与避坑指南

React中后台项目实战：从代号rea到完整前端工程化搭建

SQL注入黑名单绕过实战：从强网杯随便注到GYCTF Blacklist

更多资讯

知识工作插件化：构建可编程、可组合的智能工作流底座

SQL题目面试避坑指南：从读题拆解到查询优化全链路

知识工作插件：面向知识工作者的模块化增强协议

SchoolDB四表DDL全解析：数据库设计从字段选择到约束实践

订单表慢SQL优化实战：联合索引、覆盖索引与深分页方案

Python实战英雄联盟胜率预测：从数据清洗到SHAP模型解释

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？