REA模型详解：从资源事件代理到交易系统落地

1. 为什么是REA模型：从一次业务对齐事故说起

大概两年前，我参与某公司的一个系统重构项目，核心目标是把一套老掉牙的进销存系统换成符合数字时代节奏的新架构。需求评审会上，业务方和开发团队因为“销售出库单是不是库存减少的唯一依据”这个问题吵了整整一个下午。业务说“货出了就是库存少了”，财务说“发票开了才算应收账款”，仓库说“拣货完成但还没装车的不算发出”，三方各执一词，信息模型里根本找不到一个能同时满足三方的“事件”定义。那次会议之后我意识到，绝大多数业务系统的问题不在于技术选型，而在于从一开始就没有一个能统一表达业务语义的建模框架。

后来我深入研究并落地了一套在会计信息系统领域已经存在了几十年、但在软件工程圈子里始终不温不火的建模思想——REA模型，全称是资源-事件-代理模型（Resource-Event-Agent Model）。它不依赖某个具体数据库或者开发框架，而是一套关于“业务到底是怎么发生”的分析方法。简单说，它把一切业务抽象成三个核心概念：资源是企业拥有或控制的、有价值的东西；事件是资源发生增减变化的那一刻；代理是参与事件的个人或组织。整个企业的运行就是资源在这些代理之间、通过一连串事件不断流转。

REA模型适合谁？适合业务架构师、领域建模人员、 DDD 实践者、数据平台工程师，还有那些正在设计交易系统、订单系统、账务系统的后端开发者。它不适合纯粹当文档画着好看，它的价值必须在表结构和领域事件里体现出来。这篇文章我就以“销售发货”这个最常见的业务片段为例子，把 REA 模型的拆解、表结构落地、复杂场景处理和常见坑位一次讲透，全都是我在实际项目里验证过的做法。

有人可能会问，有了 ER 图、有了 UML 类图，为什么还要用 REA？因为传统 ER 建模是从“数据管理员”视角出发的，它关心的是怎么把数据存下来不冗余；而 REA 是从“业务参与者”视角出发的，它关心的是业务到底在什么规则下流动。前者给出的模型往往只能在当下这个业务流程形态下成立，流程一变表就要大改；后者因为业务事件本身是相对稳定的，流程怎么重组，模型核心都能稳定不动。这一点下面会展开细讲。

2. 核心思想拆解：REA不是画图套路，是一套业务操作系统

2.1 三大核心构件：资源、事件、代理

先逐个说清楚 REA 的三大构件，这是后面所有实践的基础。

第一是资源（Resource）。资源是“有经济价值、能被企业控制”的对象。存货、现金、应收账款、固定资产都属于资源，但客户关系、品牌知名度、员工技能这类“软资产”通常不适合直接建模为资源，因为它们无法用可靠金额量化，而且在事务型系统中很难捕捉到明确的事件来改变它们的状态。在实践中我建议资源表用抽象表再加子类表的方式落地，不要一上来就为库存商品、预付账款、固定资产各建一套结构完全不同的资源表，那样后面做报表汇总时会被各种 JOIN 折磨到崩溃。

第二是事件（Event）。这是 REA 的灵魂。事件表示资源在某一个时刻发生了变化，比如“出库”导致存货减少、“收款”导致现金增加。事件必须有时间、有数量的语义。一个常见误区是把“暂估入库”这类会计调整动作也当作业务事件，这在 REA 里是不允许的，因为调整动作并没有引起实际资源的真实流转，它只是账务口径的变化。真正的事件是“物资已经验收入库”的那一刻，而不是“财务后来补了一张暂估凭证”的那一刻。

第三是代理（Agent）。代理是参与事件的个人或组织。内部代理是企业内部的岗位或部门，比如仓管员、销售员、仓库；外部代理是客户、供应商、物流公司。代理和事件的关系是“参与”，一个事件至少有一个内部代理和一个外部代理参与。这条约束很关键，比如“仓库盘点”这个事件，如果模型里只有一个内部代理“仓管员”参与，而没有外部代理，那说明要么事件识别有遗漏，要么这个事件实际上不应该进入 REA 模型。

用生活类比来说明：周末你去超市买米，米（资源）从货架被拿走（事件：销售出库），你扫二维码付款（事件：收款入账），收银员（内部代理）和顾客你（外部代理）共同参与了这个过程。资源没变少吗？变了，不过超市的库存系统里它变成应收账款或者现金了。REA 就是把“米变少了、钱变多了”这个业务变换过程完整地模型化。

2.2 五种关系：事件如何把资源串起来

光有三个构件还不能表达完整的业务，REA 还定义了构件之间的经典关系，其中最重要的是五种，初学者能把下面这张表吃透，REA 就算入门了。

这五种关系中，存量流和二元性是 REA 体系的命脉。存量流保证了“资源变化守恒”，你不可能凭空造出一个事件不因其他事件而起；二元性则揭示了经济业务的本质——企业干的所有事，本质上都是“流出一样东西，流进另一样东西”。买材料是现金减少、材料增加，卖产品是存货减少、应收增加，发工资是现金减少、员工服务增加。REA 通过二元性把一个个孤立事件配成对，进而连成一条完整的价值链。

很多团队一开始会忽略触发关系和授权关系，觉得这些以后再说。实际上等到系统需要做权限控制和流程引擎驱动时，没有这两个关系的建模，事件状态流转就只能靠硬编码加状态位，每新增一个流程节点就要改一遍代码。早期把触发和授权画清楚，后续工作流引擎做事件驱动设计时会省下大量沟通成本。

2.3 为什么比传统建模方式更稳

我见过太多系统，订单表里放着订单金额，订单金额又冗余到客户表里，客户表里又冗余到业绩报表里，最后数据对不上时谁都不敢动，只能靠定时任务做各种“对账修复”。这种问题的根源在于传统的表驱动建模从一开始就把“某一次业务动作的结果”和“业务动作本身”混为一谈。

REA 对“过程”和“结果”做了强制分离。事件是过程记录，资源余额是结果状态。结果状态永远可以被事件流水重新计算出来。这有一点像财务里的总账与明细账的关系，但 REA 比总账模型更进一步，因为它能记录每一笔经济业务涉及的双方行为，而不仅是一张记账凭证。你可以在任何时候回答“这件商品从入库到出库再到开票，中间经历了哪些代理、哪些事件”，这在传统科目余额表模型里几乎不可能做到。

所以在 DDD 里用 REA 建模，得到的聚合边界通常比凭感觉划分的聚合更稳健。事件是天然的业务事实，资源是天然的快照状态，聚合根的划分逻辑就变成了围绕“事件链”进行，而不是围绕“数据关系”进行。这样设计出来的领域模型，应对业务流程调整的弹性明显更强。

3. 手把手设计一个REA模型：以销售发货为例

3.1 第一步：从业务事件切入，而不是从表结构切入

我当时在做销售子系统的时候，没有先问“需要几张表”，而是把销售环节从头到尾梳理了一遍业务事件。下面是要点，照着做就能理清自己的业务事件链。

先列业务动作清单。对销售发货来说，大致是：客户下达订单、内部审核订单、仓库拣货、仓库发货、物流签收、财务开票、客户付款。注意，这里每个动作都要问一句：有没有资源发生变化？如果分析下来发现某两个动作对应的资源变化完全一样，说明它们不是两个独立事件，应该合并。

然后给事件编号并确定时序关系。订单事件 → 审核事件 → 拣货事件 → 发货事件 → 签收事件 → 开票事件 → 收款事件。审核本身如果没有资源增减，在 REA 里不建模成资源事件，但它可以作为授权关系体现在“订单事件”上的“审批人”字段中。这一步就避免了一个非常大的建模错误：把审批记录也做成一大堆流水表，最后查询时反而不知道真正影响库存的是哪一条记录。

3.2 第二步：围绕事件识别资源和代理

事件理清后，资源和代理基本是顺着事件自然浮出来的。我建议用一张表来走查，每个事件问三件事：这个事件改变了哪个资源？哪个内部代理参与？哪个外部代理参与？

这里要特别注意“客户下达订单”这一行。订单本身不是资源，除非涉及定金预付。如果客户付了定金，那才引入“预付账款”资源，并对应一个“收到定金”事件。很多团队把订单本身当作资源去建模，结果订单的状态字段越来越多，本质原因是把“事实记录”和“经济资源”混在一起了。订单只是一组事件的信息载体，它承载的是“谁要求了什么”，而不是“什么资源被改变了”。

代理识别上，我踩过一个坑：把客户和客户的收货地址当成两个代理。正确做法是客户的收货地址是参与“发货事件”时的一个属性，而不是代理本身。如果把收货地址也建模成代理，后续统计客户价值时就得处理一大堆地址关联出来的重复数据，得不偿失。

3.3 第三步：用经济交换关系把事件串成价值链

单个事件没意义，事件只有配成对才有业务价值。第三步就是把前面的事件用“二元性”和“触发”关系串起来，形成一个完整的经济交换故事。

对销售发货来说，核心二元性就是“发货事件”和“收款事件”。发货增加了客户的应付义务，也增加了我们的应收权利；收款则反过来减少应收、增加现金。这二者是对同一经济交换的两面描述，缺一不可。如果系统里只有发货没有收款，那相当于承认企业只卖东西不收钱，显然不成立。

链条上另外还有一对二元性：采购付款场景下的“收货”与“付款”。在销售场景里，订单本身是一种承诺，它通过触发关系促使后续事件发生。所以链路上的完整描述是“订单触发发货，发货二元性对应收款”。画出来就是一个清晰的价值流闭环。带着这个闭环去和财务对账，你会发现财务要求的所有数据都能从 REA 事件表里推出来，根本不需要额外“补录”财务数据。这一点非常有说服力，也是我当年能在需求评审会上让财务同事点头的关键原因。

3.4 第四步：与会计科目体系对齐

REA 模型不是替代会计，而是让会计数据能够自动生成。落地时我建议维护一张映射表，把每个涉款事件映射到借贷复式记账的科目和方向。

以发货事件为例：库存商品减少是贷记存货科目，应收账款增加是借记应收账款科目。收款事件则是借记银行存款、贷记应收账款。这个映射表是 REA 系统与总账系统之间的桥梁。在代码里，这个映射关系绝不是用 if-else 写死的，我建议做成数据库配置表，字段包括事件类型、资源类型、借贷方向、会计科目编码。这样当会计准则调整或企业科目体系变更时，业务和开发不需要重新发布版本，只需配置刷新。

这一步做完，REA 建模阶段基本收官。此时你手里应该有一张所有业务事件清单、一组资源集、一组代理集、关系连接图，还有一张事件与会计科目的映射配置表。接下来才是真正考验功力的地方：怎么把这些设计落成表，落成存储过程，落成代码。

4. 从模型到实现：建表、持久化与DDD落地

4.1 通用REA五张核心表的SQL设计参考

下面这套表设计是我在一个模拟项目中反复修改后沉淀下来的模板，适用性比较广，也是我每次做交易类系统都会先搭好的底子。它不是一个固定答案，而是一个你可以直接参考再裁剪的起点。

-- 资源表 CREATE TABLE resource ( id BIGINT PRIMARY KEY, resource_type VARCHAR(32) NOT NULL, -- 枚举：存货、现金、应收、预付... code VARCHAR(64) UNIQUE, name VARCHAR(128), unit VARCHAR(16), -- 计量单位 current_balance DECIMAL(18,4) NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 -- 乐观锁版本号 ); -- 事件表（核心流水表，只追加，不修改） CREATE TABLE event ( id BIGINT PRIMARY KEY, event_type VARCHAR(48) NOT NULL, -- 枚举：发货、收款、收货、付款... occurred_at TIMESTAMP NOT NULL, location VARCHAR(128), ref_doc_no VARCHAR(64), -- 关联原始单据号 UNIQUE KEY uk_doc (event_type, ref_doc_no) ); -- 代理表 CREATE TABLE agent ( id BIGINT PRIMARY KEY, agent_type VARCHAR(32) NOT NULL, -- 内部代理/外部代理 agent_role VARCHAR(32) NOT NULL, -- 仓管员、销售员、客户、供应商 name VARCHAR(128) ); -- 事件-代理关联表（多对多） CREATE TABLE event_agent ( event_id BIGINT NOT NULL, agent_id BIGINT NOT NULL, role VARCHAR(32) NOT NULL, -- 发起人、审批人、收货人 PRIMARY KEY (event_id, agent_id, role) ); -- 事件-资源关联表（核心，库存流） CREATE TABLE event_resource ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, direction TINYINT NOT NULL, -- 1增加，-1减少 quantity DECIMAL(18,4) NOT NULL, amount DECIMAL(18,4) NOT NULL -- 金额，按事件发生时点认定 );

事件表设计了唯一键 (event_type, ref_doc_no)，这个细节非常关键。它从数据库层面防止了同一张业务单据被重复执行，保护了事件幂等性。我以前见过线上系统因为接口超时重试导致同一条发货单创建了两条事件记录，库存和应收全部翻倍，最后靠人工冲红才平账。有了这个唯一约束，重试只会报 Key Duplicate，不会污染数据。

事件资源关联表里的 amount 字段存的是事件发生时点的认定金额，不是最新金额。这个原则叫“历史事实不可变”。比如商品价格后来调整了，之前已经发货的事件金额绝对不能改，只能通过新的价格调整事件来修正。如果违背这个原则，后续对账、审计会全线崩溃。

4.2 折扣、退货、多币种等复杂场景怎么处理

很多人学 REA 时会觉得模型太简单，真业务里哪有这么顺滑。其实 REA 不是不能处理复杂场景，而是处理复杂场景的方式和方法不太一样。

先说折扣。一笔销售如果同时存在商品打折、整单满减和优惠券抵扣，不要把折扣拆进发货事件里把库存金额改得一团糟。正确做法是发货事件记录“按商品原价或折扣后单价计算的主营业务收入”，再把折扣额单独建模为“销售折让”事件，它是一种负向资源增量事件，或者作为发货事件的一个子类型折扣行。这样主营业务收入、折扣明细、净收入三个口径都能分开查询，财务对账时一目了然。

再说退货。退货本质上是一个反向二元性事件。正向的发货事件是库存减少、应收增加；退货事件则是库存增加、应收减少。建议不是把原事件倒号，而是生成一个新的“退货事件”，通过关联字段挂到原发货事件上。这样原事件保持不可变，退货轨迹单独审计。如果退货同时还退款，那么还要生成一个“退款事件”，与退货事件构成一对新的二元性。看到没有，复杂业务在 REA 里只是多几对二元性，不是把原来的事件模型推翻。

多币种情况我在一个跨境项目中踩过坑。事件资源关联表里的 amount 只存了本币金额，事后统计美元销售额时只能靠汇率表反算，犯了大忌。正确做法是在事件资源表上增加 currency_code、amount_original、amount_base、exchange_rate 四个字段，原币金额、本币金额、汇率在事件发生那一刻就冻结下来。后续汇率怎么波动，历史事件的业务事实都不受影响。

预算控制场景也值得一提。发货事件创建前要检查“应收账款”资源和“销售收入”事件的预算额度，这种检查逻辑放在领域服务里，通过事务保证并发安全。REA 模型不会直接告诉你预算怎么控制，但它把“可用预算”明确建模为一种特殊资源，每次发货减少可用预算余额，每次取消订单又恢复预算余额，整个控制逻辑就变得可追踪、可回补。

4.3 在DDD项目里怎么用REA辅助领域事件设计

DDD 的战术建模和 REA 其实相当互补。我调试过几个 DDD 项目后发现，凡是聚合根定义不清楚的，都可以回到 REA 里找答案。

聚合边的确定可以顺着事件链走。发货事件聚合根，资源用库存商品聚合根，代理用客户聚合根。事件聚合根持有资源 ID 和代理 ID 的引用，但不同时持有完整资源对象和代理对象。这样领域事件发布时，事件载荷里只放 ID 和必要的业务快照字段，其他详情通过查询服务获取。很多被“大聚合”拖垮性能的系统，问题就出在把资源金额、客户信用额度、代理岗位权限都塞进同一个聚合里，每次提交都要锁一大堆数据。

我推荐在领域事件类型上直接复用 REA 的事件类型。发货完成事件、收款到账事件、退货完成事件，这些领域事件本来就是对业务事实的记录。事件最终是要持久化的，直接落进上面的 event 表。这样事件溯源和关系型数据库可以同时存在，查询历史状态走事件表，查询当前状态走资源表的 current_balance 快照字段。快照失效时，用事件表重放重建余额，二者互为备份。

在最终一致性处理上，REA 也很有优势。比如“订单触发发货”这条链路上，订单服务和库存服务可能是两个独立部署的服务。订单服务可以发布 OrderPlaced（订单已下）领域事件，库存服务订阅后创建发货事件。此时通过事件表和资源表的多次查询，就能检测出是否出现“有订单但库存没有发事件”的数据缺口，再配合补偿事务，一致性比依赖分布式事务硬扛稳得多。

4.4 集成时最容易踩的账单与事件时序坑

所谓时序坑，就是业务事件发生顺序与系统处理顺序不一致。比如客户先付款后发货（预付订单）和先发货后付款（赊销订单），在 REA 里建模完全不同。

先付款后发货时，收款事件的资源变化是现金增加、预收账款增加；后续发货事件再让预收账款减少、存货减少。这里的“预收账款”是一个负债类资源，要单独建模。很多初次实践 REA 的同学会把收款事件和发货事件做成一个流水，导致发完货之后现金和应收同时虚增，月底财务对账一定会爆炸。

开票环节的处理也需要严谨。开票不等于收入确认，二者经常不是同一时刻。如果系统把开票当成收入确认事件去更新应收账款，但发货时已经把这笔收入确认了，就会出现同一笔收入被重复计算。我建议明确把开票事件建模成一个独立的“发票生成事件”，它不直接改变经济资源余额，只是生成一张税务票据，关联到对应的发货事件和收款事件。读者如果理解不了这一点，就去想你们公司的开票流程是不是经常在发货后几周才发生，这期间应收账款和收入早就应该确认了。

我可以在建表时加一个事件状态机字段，状态包括已创建、已确认、已入账、已冲销。比如生成发票后状态为已创建，等发货事件确认后状态变为已确认，再等对账完成后状态变为已入账。很多集成问题其实是事件状态没有管理好造成的，REA 事件表里加一个状态机，系统问题排查时能少掉不少头发。

5. 常见问题排查与实操心得

5.1 高频问题速查表

下面是我和团队在多个项目里反复遇到的真实问题，整理成了速查表。每个问题后面都附了排查思路和解决方案，建议收藏。

5.2 我实测下来最值得固化的三个习惯

第一个习惯是“先写事件，再算余额”。不要为了界面上的一个余额展示反推事件流水，而应该保证事件是唯一事实源，余额永远是事件流水的推导结果。哪怕要加一个余额字段做性能优化，也只能是冗余快照，不能反过来作为真数据。这个习惯能让你少面对无数个“为什么数字对不上”的夜晚。

第二个习惯是“每一笔事件都必须有明确的代理”。我排查过一次诡异的库存涨跌，原因就是事件记录里代理为空，后续做审计追溯时无法解释是谁操作的。从那以后我对事件表加了触发器，不允许代理为空。虽然看似多存了数据，但排查问题时节省的时间远超存储成本。

第三个习惯是“事件一旦生成，只能冲销，不能修改，更不能删除”。这条铁律我不多解释，谁在开发环境手滑 delete 过生产事件表谁懂。事件表只追加，不做物理删除。做冲销事件就挂负面数量，保持原事件和历史链路完整，这是审计和税务稽查最看重的底线。

5.3 什么时候不该用REA模型

你还需要知道 REA 的边界，因为盲目套用比不用更可怕。如果你做的是纯内部协作系统，比如审批流程、文档管理、项目进度跟踪，里面没有明确的经济资源在代理之间流转，REA 帮不上忙，还会让模型非常臃肿。单据审批流程直接用状态机描述简单得多。如果你做的是数据展示类报表系统，底层已经有一套稳定的宽表，那就直接基于宽表构建，不必再引入 REA 增加中间层。REA 最适合的交易型系统、核心价值链系统、供应链协同系统，这些场景下它的优势才能充分放大。

微服务拆分时也要注意，不要把整体 REA 模型硬拆到让每个服务都拥有完整的资源-事件-代理三段结构。更务实的做法是一个业务域内部保留完整的 REA 闭环，跨域之间通过领域事件和资源引用衔接。比如库存域把发货事件发出来，订单域在收到事件后更新自己的资源视图，双方各自维护本域的 REA 结构，不共享物理表，只共享事件语义。这样的边界在实践中最稳，也最符合 DDD 的限界上下文思想。

结尾：一个对我触动最深的项目案例

最后分享一个实际场景。某公司要上一套新的销售核算系统，老系统里历史数据乱七八糟，业务方一开始想的是把所有数据清洗一遍，迁移到新模型。我用 REA 提出的方案是先不迁移历史余额，而是只迁移“历史事件”，然后用事件重建所有资源余额。实施时数据量看起来大，但由于事件表结构简单、顺序清晰，新系统上线第一天就能生成出过去三年的应收账龄报表，财务同事当场惊讶，因为以前这套报表从没被生成过。

这件事给我的体会是，REA 模型真正的威力不在于它的三张表多么精巧，而在于它逼着你把业务讲清楚：谁、在什么时候、对什么资源、做了什么、和谁一起做。只要这件事讲清楚了，后面无论是做数据模型、设计领域事件、对接财务总账还是追踪审计线索，都会自然变得顺畅。它是一套业务叙事的语法，不是一堆快速生成代码的捷径。

如果你正打算重构或新建一个交易类系统，不妨先花两周时间，把自己负责的那条核心业务链上的所有事件、资源、代理画出来。不需要用任何复杂工具，一张白纸和一支笔就够。画完后你会发现，之前那些纠缠不清的流程争议，很多会自然消解。这就是 REA 能带给你的最高价值。