1. 项目定位：一个模糊代号怎么锁定业务对象模型
如果只扔给我“rea”三个字母，平时打交道的读者很容易把它当成某个目录名、“React 应用”的随手缩写，甚至是一个没写完的单词。但我自己看到之后，优先想到的是“Resource-Events-Agents”，也就是“资源-事件-代理”业务建模模型。为什么会往这个方向收？因为这三个词正好戳中了我这些年做业务系统时最常遇到的那一类问题：账目和业务动作长期分离，数据表越建越多，却越来越说不清一笔钱、一批货、一个客户之间到底是什么关系。
REA 模型最早是从企业会计语义研究里长出来的，后来被广泛用在领域建模、事件溯源、系统对账等领域。它的核心思路非常朴素：把业务世界看成三类对象的组合。资源是会被交换、消耗、生产出来的东西，比如现金、库存商品、原材料；事件是让资源发生转移或被改变的实际业务动作，比如采购入库、销售出库、收款；代理是参与事件的组织和个人，比如客户、供应商、仓库操作员、系统机器人。如果项目代号叫“rea”，我基本会假定作者想表达的就是这个三角结构，希望用一套统一语言把订单、库存、财务全面串起来。
它能解决什么问题？用一句话概括：把“记不记得住账”从一堆互相耦合的表结构里抽出来，改成先记录现实事件，再按需生成各种业务视图。它适合谁来参考？一句话描述：适合那些每天被业务部门追着改报表、被财务要求补凭证、被老板问库存到底准不准的开发团队和独立开发者。这篇文章里的所有内容，包括类型定义、事件表结构、视图投影、对账思路，都是围绕这个目标展开的，可以直接拿去套自己项目的核心域。
1.1 我判断“REA”是在说 Resource-Events-Agents 的三个依据
第一个依据来自软件领域里对这个缩写的约定俗成。在会计学术圈、语义网和领域驱动设计相关的社区里，REA 经常被作为“资源-事件-代理”本体的正式缩写使用，相关论文和企业建模案例已经积累了很多年，不是生造的术语。第二个依据是业务诉求的普遍性。只要做过进销存、订单、支付、生产制造，一定会在某个版本里被“对账”折磨得够呛，而 REA 恰好是能把业务行为和资金变动建模到同一个骨架上的一条成熟路径。第三个依据更实际：在事件溯源、CDC（变更数据捕获）、物化视图这些技术普及之后，“先落事件后投影”已经成为主流设计，REA 刚好给这些事件定义了稳定的骨架：资源是谁、代理是谁、流入流出方向、时间戳、幂等约束。
我当然不是说“rea”这三个字母只能解释成这个模型。如果你的项目确实另有含义，这篇文章里关于落地方式的思路依然通用，因为核心方法是解耦的：事件先行的取舍、资源粒度的判断、财务口径的处理，这些内容不依赖特定业务方向。从单个含糊标题解构出一套可执行建模方案，本来就是我们这种老从业者平时做的事。
1.2 它解决的问题，一句话和一张表说清楚
传统业务系统最常见的毛病，就是同一个事实被复制到多张表里维护。订单有一张订单表，库存有一张流水表，财务有一张凭证表，表面上大家都能用，实际上口径经常对不上：月底库存对不上，应收对不上，甚至一笔销售被不同部门算成了两种金额。REA 的思路是反过来的：所有业务只记录“发生了什么”，也就是事件；事件两侧挂上资源和代理；谁要什么数据，就从这个事件流里投影出什么数据。
| 对比项 | 传统“增删改查+计算表” | REA“事件+投影” |
|---|---|---|
| 核心数据 | 订单、单据、科目余额 | 业务事件、资源流、代理关系 |
| 修改方式 | 直接更新字段、补计数字 | 新增事件，历史不可篡改 |
| 对账方式 | 多表 join 后人工核对 | 同一事件流生成多个视图，口径统一 |
| 审计能力 | 依赖操作日志，往往不完整 | 事件天然就是审计日志 |
| 学习成本 | 低 | 初期偏高，中期明显下降 |
这张表里最值得注意的不是技术选型，而是思维转变。REA 本质上不关心你用什么数据库、什么框架，它首先是一种分析业务的语言。语言统一了，后面所有系统和代码层面的统一才有基础。
2. 核心原理：为什么资源、事件、代理这套三角能覆盖真实业务
2.1 传统“科目表+借贷分录”的别扭之处
做传统财务模块，第一件事是定科目表：应收账款、库存商品、主营业务收入、应付账款……每一笔业务先翻译成借贷分录，再写进总账。科目表的好处是规则统一，坏处是它把丰富多彩的业务世界拍平了。客户余额、销售成本、库存变化这些在业务人员口中很自然的问题，被强行拆成若干个科目上的数字；想看全貌，必须翻凭证、查明细、再加工不少口径。
更麻烦的是多业态场景。卖软件的、卖硬件的、做服务的都要并表，科目表要么越补越稀疏，要么一套科目下塞了无数自定义项。不同部门用同一个科目时，理解还不一样，月底对不上账成了常态。我在一些项目里见过最极端的情况：光“其他应付款”下面就有几十个明细科目，业务含义早就丢了，只剩下数字在流动。
REA 把视角倒过来了。它不先问“借什么、贷什么”，而是先问“发生了什么”。发生了什么事，意味着有哪些资源进来、哪些资源出去、谁参与。借贷分录、科目余额、利润表，这些都只是从事件流里推导出来的观点，而不是原始事实。观点可以变，事实不能变。这个差别是很多对账问题的根源，也是 REA 值得引入的根本理由。
2.2 把“账上有什么”和“实际发生了什么”拆开
做建模时我一般会画一个很简单的三角关系：代理参与事件，事件影响资源。比如一个新客户“下单”这个事件，参与的代理分别是客户和本企业；订单会创建一项“应收账款”资源，同时让“库存商品”资源流出。这里最关键的点不是用什么符号，而是要理解“流出”和“流入”都必须落到具体资源上。没有资源变化的动作，在 REA 里不叫业务事件。
用生活例子解释更清楚。买一杯咖啡，咖啡是我得到的资源，钱是换出去的资源，店员和我是代理，点单和付款是两个先后事件。一次买卖最终改变的是双方各自资源池里的数量。把场景放大到采购、生产、物流、支付，逻辑完全一致：业务链路再长，本质也是资源和代理之间的互动序列。
术语上，“存量”是指某类资源在某个时点剩下的数量，“流量”是指某个事件让资源发生的增减。库存、应收、现金余额都是存量，而采购、销售、收款这些动作产生的都是流量。REA 的核心机制，就是让每笔流量有据可查，进而让每个时点的存量都能精确推导出来。相比传统系统“改了字段就算完”的处理方式，这个机制给了业务和审计极大的安全感。
2.3 和事件溯源、领域驱动设计的关系
这里要说清楚一点：REA 不是框架，也不是现成组件，它是一个分析模型。正因为它不是框架，所以它可以和事件溯源、CQRS、领域驱动设计这些方法论自由组合。组合之后的威力相当大。
在 DDD 的事件风暴里，团队经常遇到一个尴尬场景：大家写了一堆领域事件，但每个事件该带哪些字段、以什么粒度出现，讨论半天没有结论。REA 提供了一个稳定模板：每个业务事件至少要有涉及到的资源、流入流出方向、涉及的代理、发生时间。有了这个模板，事件设计就不再是拍脑袋。事件溯源落库时，事件表只需保证追加、不可变、有序；REA 又恰好定义了资源池和代理角色，查询端投影出来的视图自然就对应库存、应收、收入这些业务概念。
我自己做系统时也发现，很多团队不是不想用事件溯源，而是害怕事件结构定义得太随意，以后没法演进。用 REA 定边界，事件结构会稳定很多。这也是为什么我常跟同行说：不要在项目一开始就引入一整套事件溯源框架，而是先用 REA 把业务事件理清楚，框架只是工具，模型才是根。
3. 概念落地：把 REA 翻译成数据结构
3.1 最小类型定义与字段解释
很多人看 REA 觉得理论味太重，不好落地。实际上翻译成代码并不复杂，我平时用 TypeScript 写微服务，落地一套 REA 的最小类型大概下面这个样子：
// 资源：会被交换或改变状态的对象 type Resource = { id: string; kind: 'inventory' | 'money' | 'receivable' | 'service_hours'; name: string; }; // 代理：参与事件并能承担责任的主体 type Agent = { id: string; kind: 'customer' | 'supplier' | 'internal'; name: string; }; // 资源流：一个事件给某个资源带来的变化 type Stockflow = { resourceId: string; delta: number; // 正数为流入，负数为流出 unit: string; }; // 业务事件：一段可审计的业务事实 type BusinessEvent = { eventId: string; eventType: string; happenedAt: string; inflows: Stockflow[]; outflows: Stockflow[]; participants: Agent[]; refId?: string; // 外部业务单号，例如订单号或发票号 };有人会问，为什么要把流入和流出分开，而不是只给一个正负号？实际场景里，一个事件经常同时影响多条资源流。比如“采购收货”会让“存货”增加，同时让“应付账款”增加，两条流的业务含义完全不同，分开表达更自然。底层存储时，你可以直接把 Stockflow 平铺成一张流水表，用一张表存事件，一张表存资源流，再加一张表存代理参与关系。代码写法可以灵活变化，但语义要保持跟 REA 对齐。
3.2 流量变存量：增量减量的计算口径
REA 最核心的计算是“流量累积为存量”。拿库存举例：每一次采购入库是“存货资源池”的流入，每一次销售出库是流出，某个时刻的存量就是所有已发生事件流量的加权汇总。做核对系统时，这个口径特别舒服，因为它天然具备准确性：只要事件记录不丢、不重复，存量自然就对。传统系统里每次手工更新“库存数量”字段，一旦某个更新漏掉或重复执行，数据就歪了。
更关键的是，流量累积出来的存量是实时可算的。订单、支付、物流这三个系统如果各自维护一份数量，月底极易对不上；但如果它们共享同一份事件流，就根本不存在“哪张表里数量多一个”的问题。应收、库存、销售成本、现金余额，全部可以用同一套机制推导，对账从“事后排查差异”变成了“事件流本身一致”。
3.3 从事件流推导会计分录
严格说 REA 不是复式记账，但它能生成复式记账。落地的做法是写一个投影函数：把每个销售事件映射成“借应收账款、贷主营业务收入”；把出库事件映射成“借主营业务成本、贷库存商品”。只要事件类型定义得清晰，会计凭证就是事件流上的纯函数计算，业务部门再也不用手工补录凭证。
这里有个重要边界：财务上很多事项跟具体业务事件不是一回事，比如折旧、坏账计提、跨期分摊。处理这类事项不能去改历史事件，而是新增一个“会计调整事件”，让事件流本身保持业务事实的原貌。我在做财务对接时，一般会把事件流分成两层：业务事件层和会计调整层。投影报表时先按业务事件生成基础分录，再叠加调整事件。这样既保证原始业务可审计，也满足财务口径的灵活性。
4. 实操过程：一个制造业场景的完整建模步骤
4.1 第一步：用动作清单摸清业务
不要一上来就画 ER 图，也不要先设计表，先把业务动作全部列出来。我习惯用一个虚构的零件加工场景来做示例：某家小型制造企业，从供应商采购铝块，加工成配件，再销售给客户。把这个场景拆开看，核心业务动作大概是六类：采购收货、采购付款、领料出库、完工入库、销售发货、客户回款。
列完动作之后，给每个动作标上三个阶段的问题：谁参与、动了哪种资源、资源的流入流出方向是什么。比如“销售发货”这个动作，参与的代理是客户和本企业，行为是让“库存商品”流出，同时形成一项“应收账款”资源。整个过程不涉及任何科目，不受科目表限制，业务人员一听就懂。
这一步做完，模型基本上已经出来了。整套模型会稳定在几十个事件类型以内，不会因为新加一个销售渠道就崩掉。新渠道只是事件数据增加，事件结构不用大改。这也是 REA 面对多业态时比科目表灵活的原因。
4.2 第二步：定义事件表、流水表和幂等约束
落库时我没有把事件以 JSON blob 一把梭存起来，而是拆成两张核心表：一张业务事件表，一张资源流水表。再加一张参与表记录代理。下面这套建表 SQL 已经在我本地多个项目里跑过，可以直接抄走：
create table business_event ( event_id bigserial primary key, event_type varchar(64) not null, occurred_at timestamptz not null, ref_no varchar(64) not null, -- 业务单号，例如 SO-2025-001 created_at timestamptz not null default now() ); create table stock_flow ( flow_id bigserial primary key, event_id bigint not null references business_event(event_id), resource_id varchar(64) not null, delta numeric(18,6) not null, -- 正数流入，负数流出 unit varchar(16) not null ); create table agent_participation ( event_id bigint not null references business_event(event_id), agent_id varchar(64) not null, role varchar(32) not null -- buyer, seller, warehouse... ); alter table business_event add constraint uq_event_ref unique(event_type, ref_no); -- 幂等约束这个唯一约束是踩过不少坑之后加上的。消息队列在分布式环境下重试很常见，如果不做幂等，同一个销售发货事件被消费两次，库存就会少算两笔，财务也会多记一笔收入。以“事件类型+业务单号”做唯一键，重复投递时直接忽略或覆盖为同一事件ID，问题就解决了。
流水表里没有单独的“方向”字段，而是让 delta 的正负表达方向。负数为流出，正数为流入。这个设计有个好处：查询存量时直接按资源分组求和即可，不需要再判断方向。业务事件本身只记录事实，哪个资源增加、哪个资源减少都清清楚楚。
4.3 第三步：用视图直接还原库存、收入与应收
建好表之后，业务查询就变成了视图层面的投影。比如要算某个商品此刻的库存，写一条 group by 的汇总：
create view inventory_snapshot as select resource_id, unit, sum(delta) as available from stock_flow group by resource_id, unit;要算一段时间的销售额，也简单，按事件类型过滤后做流入流出统计。更复杂的应收余额计算，本质也是把“销售发货”事件中的应收账款流入和“客户回款”事件中的流出做汇总。所有口径都来自同一套事件流，各部门看到数字不会再打架。
有人担心这种实时聚合在数据量大时扛不住。实际上可以分两步解决：日常查询走物化视图，底层用一个定时任务把新旧事件合并到快照里；只有需要审计追溯时，才去重新拉全量事件流回放。这样既保证实时性，也给财务留下了完整流水档案。
4.4 第四步：留一条回放与审计通道
REA 模型落地到生产环境之后，最值得花时间做的功能是“事件回放”。所谓回放，就是把某段时间内的业务事件从库里读出来，重新应用投影规则，生成那一时刻的库存、应收、利润快照。它的价值在于：任何一笔对不上的历史账，都能沿着事件流找到根因，而不是像传统系统那样只能对着最终数字猜过程。
实现方式并不复杂，核心是两套机制。一是“事件按全局序号递增”，保证回放顺序是确定的。二是“定期打快照”，比如每天零点落一份各资源存量的快照，回放时从最近一份快照开始，而不是每次都从头重算。我在项目里通常用一张快照表，记录 snapshot_id、resource_id、total、as_of_date，回放接口拿到起止时间后先找最近的快照，再叠加增量事件，速度和准确度都很可观。
5. 常见问题与排查技巧实录
5.1 资源粒度到底切多细
最常被问的问题是：库存资源到底按 SKU 建，还是按批次、序列号建？我的经验是，看业务分析的最小需要，而不是数据库建表最方便。如果只是采购、销售这种正常流转，按 SKU 建模就够了；如果有批次、保质期、追溯要求，就把“批次”这个维度放进资源池；如果每台设备都要单独跟踪维护记录，那序列号才是资源粒度。
这里有一个比较明确的避坑点：不要一开始就把资源切到“不可再拆”的粒度。粒度越细，事件数量越多，查询投影和事件回放的压力都成倍上涨。可以先按主流业务口径建模，后续真出现批次追踪需求，再通过设计“资源拆分事件”把粗粒度资源细化为细粒度资源，这种演进在 REA 模型里是非常自然的，不会破坏历史事件。
5.2 别把“改数”当“事件”
很多团队第一次接触 REA 时最容易犯的错，是把“修改订单金额到 100 元”这类更新操作当成一个业务事件去记录。区分标准很简单：业务事件必须源于现实世界的变化，比如客户支付、货物发出；而“改单”是修正之前记录的错误，属于系统整理动作。如果你把改单当成普通事件，再和业务事件混在一起做投影，很快数据就会出现双算或漏算。
正确做法是对“修正”单独建模。一个新的事件类型叫“订单金额调整”，它只影响“应收账款”资源的流动，不影响时间轴上其他事件。历史事件不允许 UPDATE，新调整只能追加。实践久了你会发现，这个原则带来的可审计性，是其他设计很难替代的。
5.3 性能：实时累计不是问题，别慌
有些人看到“所有存量都从事件流推导”，第一反应是性能会崩。实际上没这么严重。事件表可以像普通流水表一样按月分区，查询走索引；日常库存、应收查询走物化视图，不用实时全算。只有月初对账、异常追查这种低频场景才需要回放部分事件流，逻辑也简单。
我现在用的标准做法是三层：事件表保存全量明细，快照表保存每日汇总，物化视图保存当前实时状态。写入事件时同步维护快照和物化视图，用事务保证一致。生产环境里几千 TPS 的事件量，这套结构完全够用。如果事件量再大几个量级，把事件写入和投影刷新拆分到不同服务，用异步订阅去刷新物化视图即可。
5.4 财务口径和业务事件有冲突时
财务上有很多口径是业务事件里没有直接体现的，比如固定资产折旧、坏账计提、增值税申报差异、跨期收入分摊。最常见的问题就是财务人员觉得 REA 少了东西，于是要求业务加事件，结果把业务表搞得很复杂。正确做法是在事件流之上增加“会计调整层”，用专门的调整事件表存储这些会计加工信息。
我在项目里的调整事件结构基本一样：event_type 改成“accounting.adjustment”，ref_no 指向被调整的原始业务单号，delta 表示金额，再挂一个 adjustment_reason。业务报表和财务报表面向的投影函数不同，但底层事件源完全一致。这样既能保住业务事实的纯净，又能让财务口径独立演化。
6. 哪些场景适合引入 REA，哪些场景要慎重
6.1 值得用的系统有几个共同点
复盘这个 REA 项目后，我总结出适合引入 REA 的系统特征：跨模块对账要求高、业务变化快、需要审计、需要统一财务和业务口径。具体来说，只要你的系统同时涉及订单、库存、资金中任何两项，并且这些数据经常要对不上，REA 就值得试。反之，如果系统只是一套内部小工具，数据量小、变化少、没有审计诉求，那我建议保持传统 CRUD 设计，不要为了“先进”给自己增加无谓的复杂度。
拿之前一个进销存项目来说，真正值得用 REA 的只有库存、采购、销售、资金这四个核心域，而那些管理后台的字典表、用户配置、日志功能完全不需要。核心域用事件建模，外围域保持普通表，这也是我认为最优的折中方式。
6.2 如果不做全量事件溯源，怎么折中
有些团队一听事件溯源就怕，因为历史系统已经在跑，不可能推倒重来。我的建议是可以做“半 REA 落地方案”：传统表保留给非核心域，但核心链路改成事件表。比如订单和发货可以保留原表，但增加一张 slim 版的 stock_flow 表，把库存和应收的变化全部实时同步进去。这样对账时只需要查这张流水表，而不是把订单、出库单、发票多张表 join 起来核对。
这种折中方案的好处是改动小、见效快。毕竟对线账而言，最重要的不是立刻抛弃所有旧表，而是先用相同口径把变化记录下来，让所有人看到同一个数字。等到团队和业务都适应了这种口径，再逐步把旧表废除，平滑切换到完整 REA。
6.3 给团队的一条实操落地节奏
基于这些经验，我更倾向给团队定这样一条节奏：第一周只做业务事件清单，不动代码；第二周只落地事件表和一张资源流水表；第三周接上一个物化视图，让财务和库存看板开始读新口径；最后再逐步替换原有报表。每一步都小到可控，又都能立刻看到价值。
踩过不少次坑之后，我越来越觉得 REA 最有价值的地方不在于“先记事实后投影”这个技术决策，而在于它倒逼团队把业务语言统一了。开会时大家在白板上画出来的图，不管技术是否懂会计，都能指着“这个事件动了哪份资源”来讨论问题，这才是真正少走弯路的开始。后续如果继续扩展，可以加上更多的资源类型和代理角色，往业务流程引擎、AR/AP 自动核对、甚至跨公司合并报表方向延伸，底层这套事件模型都能继续支撑。
