REA模型实战：用资源-事件-主体建模，从源头解决账实不符

如果你和我一样，拿到业务需求的第一反应是“先建表”——客户表、订单表、商品表、借阅记录表，把字段撸完再写接口，那这篇关于 REA 模型 的文章可能值得你花十几分钟读完。我最近重构一个社区资料馆的借阅系统时，发现所有对不上账的诡异bug，根源几乎都是同一个：把状态当成字段存了，把余额当成字段存了，把未来承诺也当成字段存了。而一套上世纪八十年代就提出的老框架，恰好把这些问题从根上理清了。

这篇文章不会讲太多理论，重点是用一个完整的案例，带你从“传统ER建模”切换到“REA建模”的思考方式，再把概念模型映射到数据库表和代码，最后聊聊我踩过的坑和适用的边界。核心就一句话：资源（Resource）、事件（Event）、主体（Agent）三者分清楚，你的业务模型就有了审计底账，很多“账实不符”的锅根本不用背。

1. 从一场“对不上账”的库存排查说起

1.1 传统ER建模为什么越改越乱

先说那个资料馆项目。第一版需求特别简单：有图书资源，有会员，会员可以借书、还书。当时的建模方案几乎所有人都能想到——建三张表，books、members、borrow_records。books里存库存数量，borrow_records里存一个status字段，下拉值有borrowed、returned、overdue三种。

表面看没什么问题，但业务一跑起来就开始失控。第一轮加需求：图书可以捐赠入库，要记捐赠人。第二轮加需求：要支持预约借阅。第三轮加需求：采购要记账，顺便跟踪给供应商付了多少钱。第四轮加需求：图书报废注销。每一轮我都在原表上打补丁，books表里塞了current_member_id、arrival_date、source_type，borrow_records里塞了is_overdue、renew_count、operator_id，状态字段之间开始互相打架。

最经典的一幕发生在某次月底盘点：数据库里写“库存总量100本”，书架上实际只有97本。查了半天，发现有个会员还书时系统没写borrow_records，只更新了books表的库存数字，另一个接口又把status改了。谁能想到呢，当时所有人都在想是不是并发问题，但真正的问题很简单——我们根本没有一个可靠的“事实来源”。

1.2 冗余状态字段是账实不符的元凶

我一直怀疑“status字段”是很多系统的万恶之源。不是说不能用枚举，而是你一旦把“当前状态”和“历史事实”混在同一个字段里，这个字段就会变成谁都能改、改了没人知道的泥潭。

比如borrow_records.status = 'returned'，但returned_at是空；比如books.stock = 97，但没有任何一条记录解释为什么从100变成97。传统ER建模鼓励你把当前结果物化出来，比如库存数量、当前借阅人、是否逾期，这些字段确实查询方便，可它们本质上是“计算结果”，不是“业务事实”。真实世界里，账是行为和时间的累积，不是当前快照。你今天看到的库存、余额、在借数量，都应该能由一组行为推导出来，并且能解释每一步。

这就是我转向REA模型的直接动机：不想再维护一堆互相打架的冗余状态，想让数据自己“说清楚账”。

1.3 REA模型的出发点：像记账一样建模

REA是Resource、Event、Agent三个单词的首字母，中文通常翻译成“资源-事件-主体”，最早是会计信息系统领域的研究者提出的企业业务建模框架。它的出发点特别朴素：任何企业的业务活动，都可以拆成“谁（Agent）参与了什么事件（Event），事件改变了什么资源（Resource）”。

与传统的ER建模相比，REA最颠覆的一点是：事件才是核心。资源状态的变化必须由事件驱动，库存、余额这些数字都不应该直接存，而应该由事件流实时或定期推导出来。就像记账一样，流水是唯一的真相，分类账只是流水的结果。这个思路在金融、电商、进销存领域尤其好用，因为它天然带审计性——每个数字变化都能找到“是谁、在什么时候、因为什么事件”造成的。

我当时看到这个框架的第一反应是：这不就是事件溯源吗？后来才明白，REA比单纯的事件溯源多了一套严谨的语义规则，它告诉你怎么把“事件”分类、怎么表达资源增减、怎么关联主体责任关系，而不是让你拍脑袋定义一堆EventType。

2. 资源、事件、主体：三个概念怎么判

2.1 三个概念的一句话判别法

很多初学者拿到REA，最容易卡在“这个东西到底算资源还是事件”上。我总结了一个特别实用的三步判别法，问三个问题：

1. 它是否被业务主体消耗、转化、交换、借用？如果是，它是资源（Resource）。比如书、现金、借阅额度、积分。
2. 它是一个已经发生的动作或事实吗？有明确的时间点？如果是，它是事件（Event）。比如借出、归还、采购付款。
3. 它是参与或发起行为的人、组织、角色吗？如果是，它是主体（Agent）。比如会员、管理员、供应商。

“借阅记录”这个词最容易让人误会。如果你建模时把“借阅记录”当成一张表放着，要看清楚它本质上是“借出事件”和“归还事件”的集合，不是独立资源。同理，“借阅次数”也不是资源，连事件都不是，它是事件的聚合计算结果。真正需要存储的只有：某天某会员借走了一本书（借出事件），某天某会员还回来一本书（归还事件）。

2.2 存量-流动、参与、事件关联三类关系

REA把实体之间的关系分成了三类，这也是它和传统ER图的本质区别：

第一类是“存量-流动”关系（Stock-Flow），连接事件和资源，表达资源在事件中流入或流出。比如借出事件连接“图书”资源，数量是-1；归还事件连接同一资源，数量是+1。这个关系是库存余额能推导出来的根本。

第二类是“参与”关系（Participation），连接事件和主体，表达谁参与了这件事。一个事件可以有多个参与主体，比如借出事件，既有借书的会员，也有办理借阅的馆员，甚至还有审批线上预约的管理员。

第三类是“事件-事件”关系（Duality或Commitment），表达事件之间的业务因果。借出事件对应归还事件，采购事件对应付款事件，预约承诺对应实际借出事件。这一关系让系统的数据不只是“流水账”，而是一张能追溯业务链条的网。

这三类关系我建议在建模阶段先画在纸上，不要急着进数据库。等你想清楚每类关系再设计表结构，后面会顺利很多。

2.3 和普通ER图、类图的区别：多了一个审计视角

传统ER图解决的是“有哪些实体、实体有什么属性、实体之间怎么关联”，核心是名词结构。REA解决的是“业务怎么运转、事件如何改变资源、谁能负责”，核心是行为链加审计视角。

举个例子，传统ER图里books表会有“当前借阅人member_id”字段，这个字段是状态。REA里根本不会有这个字段，因为“当前借阅人”是从“借出事件未归还”里推导出来的。books表只保留这本书的ISBN、书名、存放位置等固有属性，谁借走了、什么时候还，全是事件的功劳。

REA不是要替代ER或类图，它更像是一套约束规则，告诉你哪些字段不允许出现在实体表里、哪些数据必须由事件推导。很多团队做了REA概念模型之后，落数据库还是可以用ER那套工具，但表结构的设计理念完全变了。

3. 用社区资料馆的借还业务走一遍REA拆解

3.1 按业务生命周期画出事件链

理论讲再多，不如直接过一遍案例。假设我们的社区资料馆有以下真实业务：

• 馆员采购新书，供应商供货，馆里付钱给供应商；
• 热心会员捐赠旧书，资料馆接受捐赠；
• 会员借出图书，管理员登记；
• 会员归还图书，管理员验收；
• 图书破损报废，管理员注销；
• 超期未还，收取罚款。

如果你按传统思路，第一反应是画“图书表、会员表、采购单表、借阅表、罚款表”。如果按REA思路，第一步不是画表，而是先画业务生命周期的事件链。

你会发现，整个业务流程就是一条条事件链：采购事件带来图书入库、付款事件带来现金流出；借出事件带来图书出库、归还事件带来图书入库；收货与付款配对，借出与归配对，注销与借出无关但同样是图书出库事件。这些事件链串起来之后，资源只有一个核心——图书，外加一个现金资源。

画完事件链，我心里一下子就踏实了。因为所有业务动作都是事件，未来无论加“续借”“转借”“预借”还是“赔偿”，本质上都是往事件链里增加事件类型，而不是在图书表上继续堆字段。

3.2 采购、捐赠、借出、归还这些事件怎么落地成模型

下面是我在这个项目里整理出来的核心事件类型，每一行代表一类事件，并标明它的资源方向和参与主体：

注意看采购这个场景：一笔采购会产生两个事件，一个是PURCHASE_BOOK_IN（图书流入），一个是CASH_PAY_OUT（现金流出），两个事件之间通过“采购-付款”的配对关系关联。这就是REA里最特别的“事件-事件”关系，它保证了业务不是单点记录，而是完整闭环。

归还也一样，一笔归还同时还清了借出事件对应的“未还承诺”，在数据库中我会用link_event_id把归还与借出关联起来。哪个会员借的书有没有还，一目了然。

3.3 资源的流入流出与余额推导

有了事件流，所有账目都可以动态计算，不再需要“库存数字”这个字段。具体的推导逻辑是这样的：

• 馆藏总库存 = 所有图书+1事件的总和 - 所有图书-1事件的总和；
• 在借数量 = 所有借出事件数量 - 所有归还事件数量；
• 现金结余 = 所有现金+1事件 - 所有现金-1事件；
• 某本书当前借阅人 = 与这本书相关的借出事件中，还未找到对应归还事件的那条事件的会员主体。

这套推导在SQL里也特别直白，核心就是按资源聚合事件增减量：

SELECT resource_id, SUM(quantity_delta) AS current_balance FROM event_entry WHERE resource_id = ? GROUP BY resource_id;

你可能会说，每次都SUM累加，性能是不是很差？这个问题我后面会讲快照方案，但核心思想不变：快照只是性能缓存，权威数据永远是事件流。一旦某个数字对不上，你不需要去猜，直接打开事件流从头到尾捋一遍，一定能找到问题事件。

3.4 主体边界：谁发起、谁经手、谁负责

REA对主体的建模也比较讲究，不建议所有角色都塞进一个“user_id”了事。一个事件至少要有“发起者”和“经手者”，有些场景还要有“审批者”“责任人”。在社区资料馆的模型里，我区分了两类主体：

• 内部主体：馆员、管理员，拥有操作权限；
• 外部主体：会员、捐赠者、供应商，是业务交互的另一端。

每个事件记录里都包含source_agent_id和target_agent_id。比如借出事件，source_agent_id是会员（借阅者），target_agent_id是馆员（承办人）。这个设计最大的收益在审计排查：出了问题能精准定位到“谁在什么时间做了这件事”，而不是面对一张只有created_by的订单表发呆。

我强烈建议别在资源表上直接挂“当前归属人”。比如books表不要放current_member_id字段，因为这个字段本质上是派生状态，一旦和事件流不一致，你根本不知道哪个才是真的。归属人的唯一正确来源，永远是“最近一条未归还的借出事件”。

4. 从概念模型到数据库表与代码的落地映射

4.1 表结构：事件明细表与资源台账的拆法

概念模型理清后，落地数据库就顺理成章了。我最终用的是六张核心表，而不是传统的“一张业务表加一堆字段”。

第一组是基础数据表：resource表存资源的固有属性，比如图书的ISBN、书名、位置，不存库存数量；agent表存主体信息，区分会员、馆员、供应商。

第二组是事件表：event_header表存事件头，包含事件ID、事件类型、发生时间、参与主体、外部单号；event_entry表存事件明细，包含资源ID、数量增减、单价。事件头加明细的结构，是为了支持一个事件里同时关联多个资源的情况，比如采购一批书同时包含多本不同的书，或者一笔收款同时核销多本逾期图书的罚款。

我用SQL大致表示一下核心结构：

CREATE TABLE resource ( resource_id BIGINT PRIMARY KEY, resource_type VARCHAR(32) NOT NULL, name VARCHAR(255) NOT NULL, location VARCHAR(64), unique_attrs JSON ); CREATE TABLE agent ( agent_id BIGINT PRIMARY KEY, agent_type VARCHAR(32) NOT NULL, -- MEMBER / STAFF / SUPPLIER / DONOR display_name VARCHAR(255) NOT NULL ); CREATE TABLE event_header ( event_id BIGINT PRIMARY KEY, event_type VARCHAR(64) NOT NULL, occurred_at TIMESTAMP NOT NULL, source_agent_id BIGINT NOT NULL, target_agent_id BIGINT, link_event_id BIGINT, -- 配对事件，如借出关联归还 reversed_event_id BIGINT, -- 冲销事件 ref_no VARCHAR(64) ); CREATE TABLE event_entry ( entry_id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, quantity_delta DECIMAL(18,2) NOT NULL, -- 正数为流入，负数为流出 unit_price DECIMAL(18,2) );

这个结构最大的好处是：新增一种业务动作，通常只要新增一个event_type常量，再写对应的写入逻辑，不需要改表结构。我在重构期间加“续借”功能，只花了一个多小时，这在以前的字段堆叠式设计里完全不敢想。

4.2 聚合根的划定：事件为核心还是资源为核心

从概念模型落到领域模型时，很多人会纠结聚合根到底选什么。我的建议是：以事件为核心的聚合，而不是以资源为核心。

为什么？因为“库存扣减”的一致性边界就在事件上。一次借出，必须同时完成“检查可借数量”和“写入借出事件”两个操作，否则就会出现超借。如果聚合根是resource，那么每次借出都要锁图书资源，并发高一点就会出问题。

我在工程实现里，把借出事件作为一个独立聚合根，内部包含一条图书资源的出库明细。事务边界就是：创建借出事件 + 校验并确认图书在馆。归还同理。校验逻辑可以依赖数据库的约束，比如在event_entry里对同一资源、同一事件类型做唯一约束（例如同一本书不能同时有两个未归还的借出事件），从根上避免超借。

4.3 余额查询的性能问题与快照方案

前面说了余额靠SUM推导，但有读者肯定要问：线上首页要显示馆藏数量、在借数量，每次都SUM累加，数据量大以后怎么办？

我的做法是“事件流为真相，快照表做缓存”。具体分三步：

1. 每次事件写入后，同步影响一张“资源日结快照表”，字段包含resource_id、统计日期、期初数量、流入量、流出量、结存数量；
2. 查询余额时优先读快照，快照没有覆盖到最新事件时，再用事件流补算当天的增量；
3. 快照只允许追加和更新，底层依据永远是事件流，任何修正都通过补一个修正事件来实现，不直接改快照。

实测下来，这个方案兼顾了查询性能和数据的可追溯性。即使快照表被误改了，也能重算，因为没有丢掉事件流。这比在books表里存一个随时会失真的stock字段强太多了。

4.4 事件不可变性的工程约束

REA落地最大的工程约束就是：事件不可修改、不可删除。任何写错数据的情况，都通过新增“冲销事件”来纠正，而不是UPDATE原事件。

这句话说起来容易，做起来要配合几个硬性手段。第一，数据库层面禁止对event_header和event_entry执行UPDATE或DELETE，可以靠数据库触发器或者只给应用账号INSERT和SELECT权限。第二，业务接口层不提供“修改借出记录”“删除归还记录”这样的操作，只提供“冲销”操作，冲销事件会在event_header里记录对应的reversed_event_id。

我见过不少团队在REA实践到一半，因为“业务方要求改数据”就偷偷把事件UPDATE了，结果整个审计链条断裂，账又对不上了。如果你决定走REA，一定要提前和业务方对齐这个规则：数据错了可以冲销重录，但历史足迹必须留下。

5. 关于REA的常见翻车现场与我的使用边界

5.1 坑一：把状态和承诺都塞进事件表

最容易出问题的，是把“还没发生的承诺”当成事件写进去。比如用户预约了一本书，如果直接把预约记录写成“借出事件”，那么库存余额会提前-1，图书实际还在馆里，账就虚了。

预约本质上是一种承诺（Commitment），不是事件。独立放在reservation表里，用传统状态机管理（待生效、已生效、已过期），只有预约真正转化成借出事实时，才创建BORROW_BOOK_OUT事件。过分追求“所有业务都进事件表”，反而会让事件表变成垃圾场。

我在实际项目里就把“借出承诺”和“借出事件”分开建模。预约表管流程状态，事件表管库存账目，两边通过预约单号关联，互不污染。这个边界想清楚之后，很多看似无解的对账问题自动消失了。

5.2 坑二：价格、积分、促销这类业务规则放错了层

REA建模很容易让人钻牛角尖：价格算资源吗？积分算事件吗？促销规则算主体吗？我的结论是，价格、积分、促销这些属于“业务规则和值对象”，不要硬塞进REA三层主结构里。

价格应该作为事件明细的unit_price字段保存。比如借书的押金、罚款金额、采购单价，都是事件发生时点的快照，存下来即可，不要为价格单独建模成资源。

积分如果只是“累计奖励积分”这种汇总指标，可以由事件流聚合计算，但也不必把每次积分变动都做成资源流转。只有当积分真实可以兑换商品时，才把积分建模成资源。促销规则属于承诺层或规则引擎层，在事件发生时通过规则计算最终成交价，但模型主体不需要变化。

5.3 坑三：硬套REA，把简单场景复杂化

REA很好用，但不代表所有系统都该用。我踩过一次坑，是一个纯粹的内容审核后台：待审核、审核中、已通过、已驳回，没有任何库存、余额、资源流转。当时为了统一技术栈硬套REA，结果审核状态硬要用事件推导，还写了好几个冲销接口，最后维护成本翻倍。

判断一个业务适不适合REA，我一般看三个信号：一，业务里有没有需要“盘平”的资源数量或金额；二，有没有监管或审计需求，需要回答“谁在何时做了什么”；三，有没有多主体协同产生责任追踪问题。这三个信号只要有一个明显，REA就是加分项。如果全都没有，直接用状态机反而更清爽。

5.4 什么情况下我依旧会用回传统状态机

最后的实践总结是：REA不是银弹，我更倾向于把它用在“账务核心域”，把“流程管理域”留给传统状态机。

在社区资料馆项目里，预约单、审批流、上架审核这种面向流程状态的功能，我用的是普通状态机表格；图书库存、现金账、罚款账这种需要账实相符的领域，用的是REA事件流。两者通过event_type和ref_no做关联，井水不犯河水。

这种混合方案让我越用越舒服。因为不见得全系统都需要REA，核心域管好账，流程域管好状态，各自发挥各自优势。如果你正在重构一个账目总对不平的老系统，我的建议是别想着一次性推翻重来，可以先挑库存和交易两个模块改用REA，跑通之后再逐步扩大，数据会自己用账目清爽程度告诉你这个方向对不对。

在我第一次完整跑通那套事件流推导，看到“应还数量”“实还数量”“在库数量”三项数字完全自洽的那一刻，说实话还挺有成就感的。REA模型不新，但它值得你在任何一个涉及资源流动的系统里重新尝试一遍。