如果你跟我一样，在项目的技术文档里第一次看到rea这个词，大概率会愣一下：这到底是个框架名，还是一种方法论？我之前处理一个零售系统的领域建模时，接手的旧文档里到处是 REA 三个字母，团队里没人能说清它和普通的数据表设计有什么区别。后来花了两个晚上把 Resources、Events、Agents 这条线捋清楚，才发现这套模型解决的是很多项目里最容易忽视的问题：业务逻辑、数据结构和财务口径三者脱节。
REA 模型，全称 Resources-Events-Agents，最早是会计信息系统方向提出来的业务建模方法。它不关心账长什么样，也不关心数据库表长什么样，它只关心一件事：业务是如何通过“资源被事件改变、事件由参与者发起”来运作的。这套思路用在系统设计里，可以让你在面对复杂业务时，不再被 CRUD 带着走，而是先回答三个问题：业务里有哪几类资源？资源在什么事件里发生变动？变动是由谁发起的？
这篇文章我会用图书销售系统作为例子，把 REA 的组件、建模步骤、数据库落地和常见坑位全部串起来。适合正在做领域建模、数据建模、系统重构或报表口径梳理的人参考。就算是刚接触业务建模的新手，照着我的步骤也能画出自己的第一张 REA 图。
1. 项目概述：REA 模型到底在解决什么问题
刚接触 REA 的人，很容易把它当成一种数据库建模技巧，但往深了看，它其实是一套“从业务本质出发”的系统分析方法。很多项目后期的返工、口径不一致、财务对不上账，根子往往出在建模阶段没有把业务规则说清楚，而不是写代码的人水平不够。
1.1 “REA”这个缩写的完整面貌
REA 的全称很简单：Resource（资源）、Event（事件）、Agent（参与者）。上世纪八十年代，会计信息系统方向的一位研究者提出了这套模型，最初的目的是想摆脱传统复式记账法带来的限制。传统会计用“借”和“贷”来记录经济业务，这种记录方式很成熟，但它有一个天然短板：它只记录了金额和科目，没有记录业务上下文。比如一笔收款，会计凭证上写“银行存款增加、应收账款减少”，但为什么收款？对应哪一张订单？是哪个客户付的钱？从纯凭证视角很难直接回答。
REA 模型换了个思路：不去记录抽象的借贷分录，而是记录业务事实本身。每次业务活动发生，系统记录“谁”在“什么时间”对“什么资源”做了“什么操作”。从这个角度看，会计凭证只是 REA 事件流的一个衍生视角，而非源头。后来这套模型被引入企业信息系统设计，逐渐成为业务建模和数据分析的一种重要方法。
和传统 ER 建模相比，REA 的差异很明显。传统 ER 建模的起点是实体和表，比如“订单表”“商品表”“客户表”，设计者容易先想字段，后想业务；REA 的起点是业务事件，比如“客户下单”“仓库发货”“客户付款”，先想业务怎么发生，再倒推需要哪些表。前者是数据视角，后者是业务视角，这也是 REA 在当前中台和领域驱动设计环境下重新受关注的原因。
1.2 为什么现在又重新被重视
大概在十几年前，企业信息系统还以单体架构为主，大家设计表结构时习惯直接按业务流程分模块，订单模块、库存模块、财务模块各建各的表。那时候 REA 模型显得有点“重”，因为它的建模步骤比较讲究，前期分析成本高，对交付速度要求高的团队来说不够友好。
现在不一样了。企业在做微服务拆分、数据中台建设、业务组件化时，首先遇到的就是“业务边界怎么划”和“数据口径怎么统一”。比如销售部门和财务部门对“成交”的理解经常不一样：销售看下单就算成交，财务看回款才算成交。这种“同一个业务，各说各话”的矛盾，根源在于没有一个统一的事件记录基础。REA 模型把资源变动、事件发生、参与者责任放在同一张逻辑网上，天然适合做跨部门口径的统一。
另一个现实原因是审计和合规要求越来越高。过去很多系统可以接受数据被覆盖更新，但现在讲究“数据可追溯”，讲究“业务事实不能被抹掉”。REA 模型中所有业务变动都以事件形式永久积累，天然满足审计链条完整性的要求。我曾经在某个模拟项目里帮客户梳理财务系统，对方最头疼的一点就是库存台账和总账数字对不上。后来用 REA 视角把所有库存变动还原成“入库事件”“出库事件”“盘盈盘亏事件”，立刻定位到问题出在一部分调拨单没有生成对应事件。这种问题在传统表结构设计里排查成本很高，在事件化设计里一眼可见。
2. 核心组件拆解：资源、事件、参与者
很多文章喜欢把 REA 直接讲成一种概念，但概念不落到具体判断规则上，读者还是不知道怎么用。这里我把三个核心组件逐一拆开，每个都给出判断标准和常见的混淆点，后面建模实操才不会卡壳。
2.1 资源：可以被交换、拥有、消耗的对象
资源是 REA 模型里最基础的概念，指的是企业拥有或控制的、有经济价值的对象。它可以是实物资产，比如图书、商品、原材料；也可以是货币资金，比如现金、银行存款；还可以是非实体权益，比如客户的储值余额、积分、优惠券。
判断一个对象能不能当“资源”用，我有一个比较实用的标准：它是否能在某个业务事件中发生数量增减或所有权转移，同时你能说出它的“存量”。库存可以盘点出当前数量，现金可以算出余额，甚至积分也能统计出总积分，这些都算资源。反过来，一张订单不是资源，因为订单只是业务过程的记录，它本身不会因为库存操作而“增加”或“减少”。
设计时还要注意区分“资源主体”和“资源流水”。图书信息表里存图书名称、ISBN、定价，这属于资源主体；库存表里存当前在库数量，这属于资源存量。REA 模型更关心的是存量和流量的关系，也就是“现有多少”“进来了多少”“出去了多少”。后续做报表和对账时，这三个数字缺一不可。
我遇到过不少团队把“订单金额”当成资源来设计，然后库存和财务各有一张统计表，最后两边数据永远对不齐。订单金额本质是事件发生时的度量值，不是资源增减本身。资源是钱和货，订单只是把两者联系起来的业务背景。
2.2 事件：业务动作的发生记录
事件在 REA 模型里处于核心位置。通俗地说，事件就是业务过程中真实发生的动作，比如销售事件、采购事件、收款事件、付款事件、入库事件、出库事件。
从会计角度讲，事件是改变资源存量或所有权的最小业务单元。它必须能回答几个问题：发生在什么时间？影响了哪个资源？由谁负责或谁参与？一个动作如果只更新了某个状态字段，却没有对任何资源造成影响，那它大概率不是业务事件，只是普通的信息记录。
REA 还有一种分类方式：经济事件和信息事件。经济事件指那些真正让资源发生增减的动作，比如“销售出库”会让库存减少，“收到货款”会让资金增加；信息事件则用于记录和传递信息，比如“客户提交订单”并没有立刻改变库存，甚至订单可能还没支付，但它为后续经济事件提供了依据。
我建议在设计事件表时，不要把信息事件和经济事件完全混在一起。订单提交、订单确认、订单完成这些状态变化可以作为信息事件单独记录；库存扣减、资金入账作为经济事件记录。两套事件可以用订单编号关联，但语义上必须分开。这样设计最大的好处是方便做状态机和财务对账，后面第 4 部分展开讲。
2.3 参与者：谁发起了事件
参与者是事件的发起者或相关方，可以是个人、部门、组织，甚至可以是自动化的系统角色。比如“客户下单”事件中，客户是参与者；“库管员发货”事件中，库管员是参与者；“银行自动扣款”事件中，银行系统也可以是参与者。
在 REA 模型里，参与者最好区分内部参与者和外部参与者。内部参与者指企业内部的部门和员工，比如销售、库管、财务；外部参与者指客户、供应商、物流公司等。区分这个不是闲得没事，而是因为权限和责任模型完全不同。内部参与者管理的重点在岗位职责和数据权限，外部参与者管理的重点在身份认证和合同约束。
我建议在数据库设计里不要只放一个“操作人ID”，至少要有“参与者类型”字段，比如 internal、external、system。很多做审计追溯的项目，最后都要回答“这件事是谁做的”，这个“谁”既指员工也指客户，不区分类型，后面很难在一个表里把责任链路讲清楚。
2.4 关系与二元性：REA 建模的骨架
REA 模型并不只是三个孤立的实体，它们之间的关系才是建模的核心。典型的关系有三类：
第一类，事件与资源的联系。一个事件会让一个或多个资源发生变化，比如“销售出库”让库存减少，“收款”让资金增加。这里要注意是“流入”还是“流出”，以及数量的方向和大小。
第二类，事件与参与者的联系。一个事件至少有一个参与者，通常有多个。比如销售事件，既有客户作为外部参与者，也有销售员作为内部参与者。
第三类，事件与事件之间的联系，这是 REA 模型里最精华的部分，称为“二元性”。任何经济事件都不是单独存在的。企业里几乎每个资源流入事件，最终都要对应一个资源流出事件。销售（货物流出）要对应收款（资金流入），采购付款（资金流出）要对应采购收货（货物流入），这就是经济业务的循环。
用一个生活化类比帮助理解：你去便利店买水，把水拿走是“货物流出”，把钱付掉是“资金流出”，对便利店老板来说，一进一出是一对互相匹配的事件。REA 模型要求系统在记录业务时，把这种对应关系显式地建模出来，不能只记一边。比如系统只记录了收款，却不知道是哪一笔销售带来的收款，财务月底就会一笔一笔人工核对，痛苦不堪。
从数学上看，这个关系也能导出核心的对账公式：资源期末存量＝资源期初存量＋资源流入事件合计－资源流出事件合计。这个公式是所有库存报表和资金报表的底层支撑，也是 REA 模型“自带”对账能力的来源。
3. 实操过程：用图书销售系统走通 REA 建模
理论要落到实操才有价值。这里我用一个图书销售系统作为示例，按 REA 的建模步骤一步步走。这套流程可以复制到电商、进销存、会员系统等绝大多数交易类业务上。
3.1 确定业务范围和阶段
任何建模的第一步都不是画图，而是限定范围。我假设这个系统只处理标准销售流程：客户浏览图书、下单、支付、仓库发货、客户确认收货。采购入库、退货退款、库存调拨暂时不纳入，但它们扩展起来并不难，等核心模型稳定后再加。
限定范围的意义在于快速形成最小闭环。很多团队建模失败，是因为一开始就想把所有业务一次性塞进模型，结果概念越画越多，关系越来越绕。先用核心闭环跑通 REA，再逐步扩展，成本低得多。
业务阶段上，我把它划分成三段：订单发生阶段（客户下单）、货物转移阶段（仓库发货）、资金结算阶段（客户付款）。这三个阶段对应着完全不同的资源和事件。
3.2 识别资源池
先列出系统里有哪些资源，并且定义清楚它们的存量口径。
图书库存：这是核心资源，存量口径是“当前可销售库存”，单位为册。它只包括已入库且未被锁定的图书，下订单未支付时可以先锁定但不扣减。
资金：包括银行存款或平台资金账户，存量口径是“可用余额”，单位为元。
储值余额（可选）：如果客户可以预充值，那么客户的储值余额也是资源，存量口径是“客户账户可用余额”。
积分（可选）：如果订单可以产生积分、积分可以抵扣，积分也是一个资源，存量口径是“客户当前积分”。
这里有个容易踩的坑：很多人把“应收”当资源。应收账款其实不是独立资源，它是“销售事件发生了但对应收款事件还没发生”的中间状态，可以放在事件关系里判断。把中间状态当成资源，会导致后续对账逻辑混乱。
3.3 识别核心事件流
接下来把业务过程拆成事件。下表是我为这个系统识别出的核心事件清单。
| 事件名称 | 事件类型 | 影响的资源 | 资源方向 | 主要参与者 |
|---|---|---|---|---|
| 客户提交订单 | 信息事件 | 无（暂不改变存量） | - | 客户 |
| 客户完成支付 | 经济事件 | 资金余额 | 流入 | 客户 |
| 仓库确认发货 | 经济事件 | 图书库存 | 流出 | 库管员 |
| 客户确认收货 | 信息事件 | 无 | - | 客户 |
| 订单作废（未支付） | 信息事件 | 无 | - | 系统/客户 |
注意订单支付和发货是两个独立的经济事件，而且中间可能间隔很长时间。有的业务是“先款后货”，有的是“先货后款”，REA 模型不关心业务顺序，它只关心每个资源变动都有对应事件。
3.4 补充参与者清单
参与者要区分内外，并且每个事件至少要绑定一个发起方。图书销售系统的参与者清单如下。
外部参与者：
- 客户：下单、支付的主要发起方。
- 物流公司（如果发货要记录）：承接发货运输的外部机构，在收货确认时关联。
内部参与者：
- 销售员/客服：协助客户下单，处理订单问题。
- 库管员：负责确认发货，触发库存出库事件。
- 财务人员：负责核对收款，处理退款。
- 系统：自动执行订单状态流转等操作。
在事件表设计中，我的习惯是用两层字段：发起方参与者（agent_id）和参与角色（role_type）。比如“仓库确认发货”事件，发起人是某个库管员，role_type 是 internal。这样以后做权限控制和责任追溯都很方便。
3.5 用关系表表达模型
不用画复杂的流程图，文字和表格能把关系说得更清楚。这个系统的核心关系可以这样列：
- 客户提交订单事件（信息事件）关联：客户参与者；后续触发支付事件和发货事件。
- 支付事件（经济事件）关联：客户参与者、资金资源（流入）；与销售事件存在二元性配对。
- 发货事件（经济事件）关联：库管员参与者、图书库存资源（流出）；与支付事件共同构成一笔销售闭环。
- 每笔完成销售，应满足：库存流出的图书数量、收到的资金金额与订单明细一致。
写完关系表后要做一次完整性检查：每个资源增减都被事件覆盖；每个事件至少关联一个参与者；每笔经济事件都找到配对事件或明确标记为“待配对”。
3.6 这样设计的意义
这个模型和普通表结构设计最大的区别，是把“订单”从中心位置拿掉了。传统系统会说“订单是主表，订单明细、支付流水、发货流水都是子表”，REA 模型会说“订单只是一系列事件的聚合视图”。
两种设计在简单业务里差别不大，但在复杂场景下差别明显。比如客户先付了 100 元，结果图书缺货，只发了 60 元的货，剩下 40 元变成余额。传统模式下要在订单表、支付表、退款表之间反复改状态；REA 模式只是多了一个“退款事件”，再把支付事件和发货事件金额重新配对，语义清晰得多。
4. 数据库落地：把 REA 模型映射成表结构
模型画得再漂亮，最终也要落到数据库里。REA 模型到数据库的映射并不复杂，核心是几张表：资源表、事件表、参与者表，以及事件-资源明细表、事件-事件配对表。
4.1 表结构设计示例
我给出一个简化但不是玩具级的建表设计。这里只展示关键字段，项目中可以按实际情况补充创建时间戳、操作人等公共字段。
先建资源表，用来描述资源主体和当前存量：
create table rea_resource ( resource_id bigint primary key, resource_code varchar(50) not null unique, resource_name varchar(200) not null, resource_type varchar(20) not null, -- BOOK / CASH / BALANCE / POINTS unit varchar(20) not null, -- 册 / 元 / 分 current_qty decimal(18, 4) not null default 0 );再建参与者表：
create table rea_agent ( agent_id bigint primary key, agent_code varchar(50) not null unique, agent_name varchar(200) not null, agent_type varchar(20) not null -- internal / external / system );事件表是核心，记录每个业务事实：
create table rea_event ( event_id bigint primary key, event_type varchar(50) not null, -- ORDER_SUBMIT / PAYMENT / DELIVERY event_time timestamp not null, business_time timestamp not null, agent_id bigint not null references rea_agent(agent_id), event_status varchar(20) not null, -- PENDING / CONFIRMED / CANCELLED / PAIRED ref_order_id bigint );事件明细表，记录当前事件影响了哪些资源：
create table rea_event_line ( line_id bigint primary key, event_id bigint not null references rea_event(event_id), resource_id bigint not null references rea_resource(resource_id), quantity decimal(18, 4) not null, direction varchar(10) not null, -- IN / OUT amount decimal(18, 2) );事件配对表，记录事件之间的二元性关系：
create table rea_event_link ( link_id bigint primary key, src_event_id bigint not null references rea_event(event_id), tgt_event_id bigint not null references rea_event(event_id), link_type varchar(30) not null, -- SALES_TO_PAYMENT / etc. link_amount decimal(18, 2) );这套结构和经典 ERP 里的“分录”很像，但事件表更贴近业务语义。直接用这套表，就能回答“这个月销售了多少”“实际回款多少”“库存还剩多少”一类的问题。
4.2 关键约束与业务规则
表只是载体，规则才是灵魂。落库之后至少要实现这几类约束。
事件明细必须引用已有资源。任何一条 event_line 的 resource_id 都不能为空，也不能引用已废弃的资源记录。这一点可以在应用层强校验，也可以在数据库用外键保证。
经济事件必须有方向。每条明细要么是资源流入，要么是资源流出，不能两个方向都写。用 direction 字段加 CHECK 约束：
alter table rea_event_line add constraint chk_event_line_direction check (direction in ('IN', 'OUT'));事件配对金额不能超过源事件金额。比如一笔支付事件配到多个销售事件，配掉的金额不能超过支付总金额。这个约束放在数据库里比较难写，一般由应用层在“配对核销”服务里保证，数据库只负责记录配对结果。
资源存量不能为负。这个最容易被忽略。库存扣减、余额扣减都需要在事务里做条件更新，或者用数据库锁配合校验。我见过很多系统因为“库存显示负几百”而出报表事故，查到最后全是扣减时没有做防负校验。
事件表只增不改。除非数据录入错误，否则已经生成的事件记录不应该做物理删除。处理错误用“红字冲销”或“反向事件”，也就是生成一条反方向事件来抵消原事件的影响。这个设计是老会计系统验证过的，现代业务系统同样适用。
4.3 报表和对账的便捷性
REA 模型落地后，报表不是“额外开发”的，而是从事件表里直接推导出来的。
库存报表：对图书库存资源，按方向聚合所有出库和入库事件，就能得到任意时间点的理论库存。如果再和资源表里的 current_qty 核对，就能发现哪里有漏记的流水。
销售报表：对支付事件按业务时间聚合，得到的是“回款口径”的销售额；对发货事件按发货时间聚合，得到的是“发货口径”的销售额。两种口径不再需要开发两套报表，只是按不同事件类型过滤同一张事件表而已。
应收账龄分析：找出已经发货但还没支付的事件对。REA 模型天然支持这种查询：在事件配对表里，给发货事件找支付事件，找不到或者只找到部分金额的，就是未完成配对，就是应收。
这种通过事件流“推”报表的路径，比传统业务报表开发省掉大量聚合逻辑。我第一次做 REA 落地时，本来计划三天的报表开发，只花了半天就把核心口径写完了。
5. 常见问题与排查技巧实录
REA 建模不像 SQL 语法那样有绝对标准，每个人在实操中都会遇到各种偏差。这里列举我实际踩过并且处理过的高频问题，按症状、原因、排查思路来写。
5.1 资源与事件概念混淆
最常见的现象是团队在讨论模型的时候，把“资源变动”和“状态变更”混为一谈。比如有人说“客户退单了，订单状态改成已退”，这其实只发生了一个信息事件，并没有资源变动。但如果退单的同时还要把钱退回给客户，那资金余额就发生了流入，就必须补一条退款经济事件。
排查方法很简单：对着每一个业务动作问一句“它到底改变了什么资源？”如果回答不上来，说明这个动作可能只是个状态记录，或者资源识别漏了。有了问题意识，建模讨论就会不断往业务本质靠拢。
我还遇到过一个真实的例子：一个仓储系统统计损耗时，只更新了库存数字，却没有记录损耗事件。结果月底财务问“损耗的货去哪了”，系统答不上来。这就是典型的“只改了结果，没记录原因”。
5.2 订单和支付时间差导致统计异常
交易系统普遍存在“下单时间”“支付时间”“发货时间”不一致的情况。如果用下单事件去统计销售额，回款数据就永远是偏晚的；如果用支付事件去统计发货量，又会把已支付未发货的订单算进去。
我的建议是先把业务时间拆成两类：事件发生时间（event_time）和业务归属时间（business_time）。例如支付事件的发生时间是支付那一刻，业务归属时间可能是客户实际享受服务的日期。报表一律以业务归属时间统计，而审计以事件发生时间为准。这样一个订单跨月支付的情况，就不会把账记错月份。
这个坑我在做了一期经营分析报表之后才彻底想明白。原本所有收入按月支付时间汇总，表面看没问题，可遇到月底集中支付的时候就乱套，后来改成按业务归属时间梳理，报表才稳定下来。
5.3 内部和外部参与者边界模糊
很多系统用一张 users 表区分客户和员工，但业务事件表里只记录“操作人ID”。等要做审计追溯时，才发现一个人员角色变了，或者一个账号同时绑定了内部和外部身份，历史事件归属说不清。
我的经验是：事件表里除了参与者ID，至少还要冗余一个参与者类型字段。角色可以变，人员可以离职，但事件发生那一刻的参与者身份必须固化下来。哪怕你后续对人员表做了合并拆分，审计追溯仍然有据可查。
权限控制也是同理。库管员只能发起发货事件，财务只能发起支付确认，这种权限模型的落点不应该在普通页面路由上，而应该在事件写入服务层。REA 模型把权限落到“谁能触发哪个事件”上，比落到“谁能访问哪个菜单”上更贴近业务。
5.4 二元性关系遇到复杂业务
多对多配对是这个模型里最容易让人头疼的部分。比如客户一笔订单买了三本书，分两批发货，一次付款。按经典 REA 方式，应该把支付事件和两次发货事件分别配对，形成一个“一对多”结构。这个没有本质难度，但实现层要处理好金额分配。
部分退款和多次退款更是如此。我建议先实现“部分配对”概念：事件配对表允许同一源事件和多个目标事件形成多条 link，每条 link 记录配对金额，同时源事件维护一个已配对金额。只要已配对金额不超过源事件金额，业务就是安全的。
如果业务特别复杂，比如预售、定金、尾款、多次补差价，不建议一开始就把 REA 模型设计得特别精微。先按“核心事件流”走通，再逐步放开配对的复杂度。模型服务于业务，不是业务服务于模型。
5.5 排查速查表
下表是我整理的 REA 建模常见问题速查，可以直接贴在项目文档里供团队参考。
| 症状 | 可能原因 | 建议排查方向 |
|---|---|---|
| 报表库存和实物库存对不上 | 缺少出库、入库或盘盈盘亏事件 | 按资源分组检查事件明细，定位缺失时间点 |
| 财务回款和销售订单对不上 | 收款事件未关联到销售事件 | 检查事件配对表，找出未配对或部分配对的支付记录 |
| 订单状态异常，卡在某个状态 | 信息事件和经济事件混淆 | 检查订单状态变更是否对应实际资源动作 |
| 历史数据审计困难 | 事件被物理删除或覆盖 | 严格禁止物理删除，设计正向和反向事件 |
| 部门间统计口径不一致 | 不同团队用不同类型事件统计 | 统一报表口径，明确使用哪个事件作为基准 |
| 负库存出现 | 扣减时未做防负校验 | 在事务中做条件更新，或引入库存预占机制 |
这些坑并不可怕，可怕的是没有设计思路，等出了问题才在全国到处救火。按照 REA 的原则梳理一遍，大部分问题都会暴露在建模阶段，而不是上线阶段。
6. 进阶扩展：REA 模型驱动的自动对账与审计线索
如果前面的动手步骤你已经走通，接下来可以玩点更有价值的东西。REA 模型不只是建模手段，它在“自动对账”和“审计追踪”场景下的表现尤其亮眼。
6.1 自动对账的本质是事件配对
对账这件事，传统方案常常是导出两张 Excel，然后用 vlookup 匹配，费时费力还容易漏。用 REA 视角看，对账就是事件配对，核心逻辑就三步。
第一步，拿出一个事件集合，比如发货事件集合；第二步，拿出另一个事件集合，比如收款事件集合；第三步，按参与者、时间窗口、金额一致性做匹配，匹配上的写进事件配对表，匹配不上的标记为“待核查”。
我做过一个模拟项目，把这种方式聚合成一个“自动核销服务”后，原来财务每天一个小时的人工核对工作被压缩到了几分钟，剩余的异常单才需要人工处理。这种收益不是虚构的，而是事件化设计天然带的。
实现的时候建议保留一个字段叫“匹配状态”，例如 UNPAIRED / PARTIAL_PAIRED / PAIRED，方便追踪每一笔资金流和货物流的完整生命周期。很多查账问题最后都会落到“为什么有一笔支付没有关联到销售”，有了状态字段定位会非常快。
6.2 把审计线索完整串起来
传统系统做审计追溯，要跨订单、支付、库存、日志好几张表慢慢查。REA 模型里，所有审计线索都围绕事件表展开。
想查某本书的所有去向，只对“图书库存”资源过滤所有出库事件，就能得到完整的销售、调拨、报废记录；想查某一个客户的所有业务，按外部参与者 ID 过滤所有事件，就能看到他从注册、下单到支付的全过程。链接不需要临时拼凑，因为它本来就是按语义建模的。
我还建议在事件表上预留一个“业务单号”字段，用来关联其原始单据号，比如订单号、发票号等。这是语义模型和实际业务单据之间的一座桥。REA 提供因果关系，而业务单号提供凭证依据，两者配合，审计要求基本都能满足。
6.3 扩展现有模型的建议
前面图书销售系统只做了标准销售闭环，实际业务还可以继续加：采购事件，对应图书库存流入和资金流出，与销售流程形成完整业务循环；退货退款事件，其实是在原支付事件和原销售事件之间生成反向事件；库存调拨事件，涉及两个仓库资源，一个方向为 OUT，另一个方向为 IN。
每次新增业务，都先按“资源-事件-参与者-配对”四个维度走一遍，基本不会漏掉关键环节。如果团队希望长期复用这套方法，建议沉淀一份 REA 建模模板，每次开新项目时直接按模板提问，效率会高很多。
另外说一个我自己的实操偏好：REA 建模最好在数据库建表之前做，而不是之后。先有事件语义，再推导表结构，改动成本最低。如果已经在传统结构里跑了很久，也不急着推倒重来，可以先把核心事件表和事件明细表建出来，和旧表并行跑一段时间，用对账结果验证模型的完备性。数据一致了，再逐步切换。
这个方法我在多个模拟项目里验证过，最深的体会是：REA 不是银弹，但它能逼着你在写第一行代码前把业务想清楚。业务里最难回答的问题从来不是“这个表怎么写”，而是“这笔业务到底发生了什么”。想清楚这一点，后面的开发、报表、审计都会轻松得多。
