最近总看到有人发“rea”这个词。第一反应可能以为是某个前端框架的新版本等点进去聊起来才知道是 Resource、Event、Agent 的缩写一套已经有几十年历史、但这两年重新被企业系统设计者翻出来讨论的业务建模模式。我在这篇里把它讲透什么是 REA、它到底比其他建模方式好在哪、怎么从一张业务事件图落地成真正能跑的数据表以及我用它在三个模拟项目里踩过的那些坑。如果你是做后端、数据模型或者企业系统重构的这篇会给你一套可以直接抄走的建模模板。当时我接手一个电商经营分析系统最大的痛点是订单、库存、财务各拿各的数据口径月底对账对到怀疑人生。后来我把底层模型整个换成 REA 的思路重做了一遍才发现很多历史遗留问题根本不是数据质量问题而是从一开始建模就建错了。所以这篇不是理论科普是拿真实项目说话的经验贴。1. 为什么我会去研究 REA 这种建模模式1.1 从一张做不平的损益表说起做业务系统做得越久越能体会到一件事大部分系统在建模时都把“业务事实”拆碎了。订单系统关心状态流转库存系统关心进出流水财务系统关心借贷分录。同一个动作比如“顾客付钱买了一杯咖啡”在订单库是一行订单记录加一个状态位在库存库是库存表的扣减在财务库是借银行存款、贷主营业务收入。表面上各系统跑得都挺正常可一旦要跨系统对账、做经营分析、追溯异常订单就会发现数据的语义已经对不上了。我经历过一次特别典型的对账事故销售系统和财务系统用的是同一个订单号但财务的确认收入时间取的是“支付时间”销售系统取的是“发货时间”两边各差一天月度报表数字怎么都对不上。后来一查不是程序 bug是当初建模时“收入到底在哪个环节确认”这件事根本没被显式定义只是各自系统里顺手选了个时间字段。当时我就在想能不能有一种模型不依赖单据状态、不依赖借贷科目而是把业务本身最核心的“资源在谁手上发生了什么事”记录得原原本本。REA 就是在这种背景下被我从资料堆里翻出来的。1.2 REA 到底是什么三个词说清REA 是 Resource、Event、Agent 三个英文单词的缩写翻译过来是资源、事件、代理。它最早是上世纪八十年代在会计信息系统领域被提出的一套建模框架目的是替代传统复式记账模型让计算机系统能够直接表达真实世界的经济活动而不是只记“借和贷”。资源Resource一切有价值、可以被经济主体控制和使用的东西比如现金、库存商品、原材料、设备、服务工时。事件Event改变资源状态或资源归属的动作比如采购收货、销售出库、现金收款、现金付款、生产领料。代理Agent参与事件的个人或组织比如客户、供应商、员工、门店、仓库部门。用买咖啡举例子顾客支付 22 元现金购买一杯美式这里面现金和咖啡是资源收银员收款、咖啡出杯是事件顾客、收银员代表门店是代理。传统模型会纠结“这笔钱是记到现金还是银行存款”REA 只关心一件事谁的什么资源发生了什么变化。这里最关键是思维转换不要用“单据”作为建模中心要用“事件”作为建模中心。订单、发货单、收款单都只是事件的载体或凭证而不是事实本身。1.3 REA 与复式记账不只是换了个名词复式记账的思路是给每笔经济业务打上“借贷”标签通过恒等式保证账目平衡。它为解决“钱从哪里来、到哪里去”这套会计语言而生非常强大但也有一个副作用它把连续的业务过程截断成了一个个分录片段偏离了业务人员的语言习惯。我问过很多业务同事“主营业务收入是什么意思”他们能答上来但问“什么动作算确认收入”答案五花八门。这不是业务不专业而是财务语言和业务语言本来就不是一回事。REA 的思路是先把业务事件记录清楚然后从事件记录上随时投影出“会计视角”的账表。也就是说你可以用一套事实数据生成多种视角的报表而不是一开始就把数据定义死成某一种视角。我用一张表对比过对比项复式记账REA核心对象会计科目、借贷分录资源、事件、代理记录内容金额增减谁在何时对什么资源做了什么时间语义记账时间业务发生时间与系统记录时间分离审计追溯从分录反查单据困难从事实直接回放业务过程学习成本财务人员低成本研发和业务都需要换个思路刚开始我自己也犯过嘀咕REA 这么好为什么没普及后来想明白了不是模式不好而是很多系统压根不需要那么强的业务事实还原能力。等到你真要接审计、做经营分析、搞多系统融合的时候REA 的优势才凸显出来。2. 落地前先想清楚REA 的核心构件怎么落实到业务2.1 先画一张事件图而不是先画原型用 REA 建模时我习惯的第一步永远不是打开数据库画表而是在白板上把“业务事件图”画出来。和普通流程图不同的是事件图关注的是资源流动的方向。还是拿咖啡店说事。假设一个简化版的咖啡店涉及的核心资源有咖啡豆、杯装咖啡、现金。核心代理有顾客、供应商、门店。这个业务里至少有下面几个事件供应商送货咖啡豆从供应商流入门店的咖啡豆库存。向供应商付款现金从门店流到供应商。门店制作咖啡咖啡豆从库存状态转换成杯装咖啡这个过程消耗咖啡豆、产出咖啡。顾客购买咖啡一杯咖啡从门店流到顾客。顾客支付现金现金从顾客流到门店。注意这里有个关键点普通系统会把“顾客购买咖啡”拆成“订单创建、订单支付、咖啡制作、咖啡交付”四个状态而 REA 会把它们拆成“销售咖啡、收到现金”两个核心事件制作咖啡看成资源转换事件。状态只是多个事件发生后的结果不是存储在订单表里的一个字段。我建议你在落地前先做一张不超过 20 行的表格列清楚三列事件名称、导致哪些资源发生什么变化、参与代理有哪些。这一步做完后续表结构基本就定了根本不需要拍脑袋。2.2 两类经济活动交换与转换REA 把经济活动分成两大类这一点非常影响表结构设计。交换Exchange资源在不同代理之间流动通常是“给出一项资源换回另一项资源”。比如销售咖啡换回现金采购咖啡豆付出现金。交换最关键的是“经济互惠”一笔销售通常伴随一笔收款一笔采购通常伴随一笔付款。这两个配对事件是保证账实一致的基础。转换Conversion资源从一种形态变到另一种形态通常发生在生产制造或服务过程中。比如咖啡豆经过烘焙、研磨、冲泡变成杯装咖啡原材料变成产成品。转换通常不改变资源的代理归属只改变资源的形态和位置。大部分进销存项目只实现了交换类事件仓储结构也建得很细结果一碰到生产过程就开始往库存表里硬塞“加工中”“损耗”“半成品”这些状态把模型搞得乱七八糟。我后来在 A 公司重构供应链项目时把“生产领料”和“产成品入库”明确建模成转换事件生产部门的数据才真正准确。2.3 承诺层到底要不要做REA 理论里还有一个概念叫“承诺”Commitment指已经约定但尚未执行的经济事项比如销售订单、采购合同。承诺本身不是事件它是事件的前置契约。很多人在建模时纠结一个问题要不要把订单单独建表还是直接用事件表表达我的建议是分情况。如果你的系统只是做简单的进销存不需要跟踪订单履约率、不需要做复杂的信用控制那完全可以把“订单”作为业务凭证编号放在事件表里用 status 字段控制状态等履约完成后把状态置为完成。这样做最简单报表也最好出。如果你的系统是订单履约中台或供应链协同平台那必须把承诺层单独建模。因为一个订单承诺可能拆分成多次发货、多次收款它们是多对多关系。你如果没有独立的承诺表根本没法回答“这张订单还有多少没发、多少没回款”。我在某跨平台系统里就是采用了承诺与事件分离的模型订单头存在于订单聚合中履约时生成发货和收款事件二者通过业务编号关联。查询进度的时候用聚合查询追溯事实的时候用事件流两边都很顺手。3. 可复现的落地案例一个咖啡店进销存的 REA 模型3.1 表结构怎么设计直接给一套可以跑的 PostgreSQL 表结构这个结构能覆盖咖啡店的基础进销存场景你先照抄再去改。资源表CREATE TABLE resource ( resource_id bigserial PRIMARY KEY, name text NOT NULL UNIQUE, resource_type text NOT NULL CHECK (resource_type IN (PHYSICAL_ITEM, CASH, SERVICE)) );代理表CREATE TABLE agent ( agent_id bigserial PRIMARY KEY, name text NOT NULL, category text NOT NULL CHECK (category IN (CUSTOMER, SUPPLIER, EMPLOYEE, STORE)) );事件表这是核心CREATE TABLE economic_event ( event_id bigserial PRIMARY KEY, event_type text NOT NULL, happened_at timestamptz NOT NULL, entered_at timestamptz NOT NULL DEFAULT now(), resource_id bigint NOT NULL REFERENCES resource(resource_id), from_agent_id bigint REFERENCES agent(agent_id), to_agent_id bigint REFERENCES agent(agent_id), quantity numeric(18, 6) NOT NULL CHECK (quantity 0), unit text NOT NULL DEFAULT USD, business_key text NOT NULL UNIQUE, metadata jsonb );事件关联表CREATE TABLE event_link ( id bigserial PRIMARY KEY, left_event_id bigint NOT NULL REFERENCES economic_event(event_id), right_event_id bigint NOT NULL REFERENCES economic_event(event_id), relationship_type text NOT NULL CHECK (relationship_type IN (TRIGGERS, MUTUAL, CONVERSION)) );用 from_agent_id 和 to_agent_id 表达资源的流动方向比单个 agent_id 更精准。一次销售事件中咖啡从门店流向顾客一次收款事件中现金从顾客流向门店。方向反了还能顺藤摸瓜查出问题。3.2 一条完整业务怎么插入事件假如 2025 年 3 月 20 日顾客 A 在门店花 22 元买了一杯美式咖啡。这一笔业务会生成两个事件销售事件和收款事件它们之间用 MUTUAL 关系关联。先插入资源数据和代理数据然后插入事件BEGIN; INSERT INTO economic_event ( event_type, happened_at, resource_id, from_agent_id, to_agent_id, quantity, unit, business_key ) VALUES ( SALE, 2025-03-20 10:15:0008, (SELECT resource_id FROM resource WHERE name 美式咖啡), (SELECT agent_id FROM agent WHERE name 门店), (SELECT agent_id FROM agent WHERE name 顾客A), 1, 杯, ORDER-20250320-0001 ); INSERT INTO economic_event ( event_type, happened_at, resource_id, from_agent_id, to_agent_id, quantity, unit, business_key ) VALUES ( CASH_RECEIPT, 2025-03-20 10:15:0008, (SELECT resource_id FROM resource WHERE name 现金), (SELECT agent_id FROM agent WHERE name 顾客A), (SELECT agent_id FROM agent WHERE name 门店), 22, USD, ORDER-20250320-0001-PAY ); INSERT INTO event_link (left_event_id, right_event_id, relationship_type) SELECT sale.event_id, payment.event_id, MUTUAL FROM economic_event sale JOIN economic_event payment ON payment.business_key ORDER-20250320-0001-PAY WHERE sale.business_key ORDER-20250320-0001; COMMIT;这里有一个容易被忽略的细节两个事件虽然业务上属于同一笔订单但它们是独立的两条记录各自有业务编号。业务编号的唯一约束就是幂等防线数据管道重放时不会产生重复事件。3.3 时间维度业务时间和记录时间必须分开我刚用 REA 建模时犯过一个错误事件表只存了一个 created_at。后来盘点时发现有些销售单是第二天补录的按创建时间统计收入就会失真。事件表里必须区分两个时间happened_at业务实际发生的时间。谁在什么时候实际交付了咖啡实际收到了钱。entered_at系统什么时候把这条事件写入数据库。补录、批量导入都能在这找到痕迹。这两个时间一旦分开审计和统计口径就都稳了。统计营业额按 happened_at排查数据问题按 entered_at。补录行为的检测也简单比较两个时间的差值即可超过阈值自动告警。提示我给所有事件表都强制加了这两列业务上可以不用但后台排查和财务审计一定会用到早加早省心。4. 有了模型之后报表怎么出投影Projection才是关键4.1 从事件还原库存余额REA 模型把库存从“一个数字字段”变成了“一组事件流”。想知道库存还有多少把流入事件和流出事件加总即可。我建议不要每次查询都现算事件而是建一张投影表或物化视图定时从事件表聚合刷新。以咖啡豆库存为例可以这么写CREATE MATERIALIZED VIEW stock_projection AS SELECT resource_id, SUM( CASE WHEN event_type IN (PURCHASE_RECEIPT, PRODUCTION_OUTPUT) THEN quantity WHEN event_type IN (SALE_DISPATCH, PRODUCTION_INPUT, WASTE) THEN -quantity ELSE 0 END ) AS stock_balance FROM economic_event GROUP BY resource_id;这里的关键点在于事件表里 quantity 永远是正数流入流出方向由事件类型决定。这样写的好处是任何一条库存流水都能向上追溯到原始事件查账时不用在库存单据和实际业务之间来回翻译。物化视图刷新不要太频繁建议按需刷新或者每 5 分钟一次。库存查询请求量大就加缓存别为了一个报表把每次查询做成全表聚合数据库扛不住。4.2 从事件生成营业收入和现金流收入报表同样可以从事件表直接投影。先建一个销售事件视图再按天聚合CREATE VIEW sale_event_view AS SELECT e.*, r.name AS resource_name FROM economic_event e JOIN resource r ON r.resource_id e.resource_id WHERE e.event_type SALE;然后按天统计销售额SELECT date_trunc(day, happened_at) AS sale_day, COUNT(*) AS order_count, SUM(quantity) AS cups_sold FROM sale_event_view GROUP BY 1 ORDER BY 1;需要特别提醒的是营业收入、应收账款、现金流量这些财务指标在 REA 里都是“投影”而不是“原始事实”。销售事件发生意味着收入确认收款事件发生意味着现金流入。如果这两个事件都齐了对应的订单才算完整闭环。用 event_link 的 MUTUAL 关系可以做账龄分析很久还没有配对收款事件的销售就是潜在的风险订单。4.3 要不要引入财务影子表这块是我踩坑最多的地方也是很多人对 REA 最困惑的地方。REA 模型不等于会计系统它记录的是业务事实不直接生成法定财务报表。现实中要满足税务、审计要求还是得有凭证、总账、科目余额这些东西。我的做法是加一层“财务投影”。REA 事件表是基础事实层财务影子表是表达层。事件发生后通过一个同步任务把事件翻译成会计凭证。翻译规则写在配置表里比如销售事件对应“银行存款/主营业务收入”采购事件对应“库存商品/银行存款”。这层做上去之后业务部门和财务部门终于不用再争数据口径了。业务部门查事实财务部门查投影两边共享同一套底账。影子表不一致就是翻译规则的问题而不是业务数据的问题排查范围瞬间缩小了一个数量级。5. 与主流架构的关系怎么和 DDD、事件溯源共存5.1 REA 与 DDD边界要跨但不要打散用过领域驱动设计的朋友都知道聚合边界内强调一致性边界外讲究最终一致。REA 事件天然是跨聚合的比如一次销售事件同时涉及订单聚合、库存聚合、支付聚合。你不可能让一个聚合既管订单状态又管库存扣减又管资金记账这样聚合会大到失去意义。我的方案是DDD 聚合负责处理业务规则和命令REA 事件层负责记录事实。订单聚合校验通过后发布领域事件另有一个事件订阅器把领域事件转换成 REA 经济事件落库。这样领域模型保持完整REA 模型保持稳定两边各干各的活。这里有个实践细节不要把 REA 经济事件直接作为 DDD 领域事件来用。REA 事件更接近“事实记录”而 DDD 领域事件更接近“已发生的业务动作”两者语义有差别。我一般是先发领域事件再拿领域事件的数据生成 REA 事件这样责任清晰不会出现改一个事件同时影响多个聚合状态的情况。5.2 REA 与事件溯源一个语义层一个存储层好多人会把 REA 和事件溯源搞混。事件溯源是一种存储与状态重建的模式所有状态变化都通过重放事件来恢复REA 是一种业务建模模式它定义事件应该包含什么语义、事件之间是什么关系。两者可以结合得很深可以把经济事件表当作事件溯源的事件日志通过重放事件重建库存余额、应收余额等投影状态。关键是“命令”和“事实”要分离用户提交订单是命令订单履约成销售事件是事实。不要把用户操作、按钮点击、API 请求都当成 REA 事件存起来那样模型会迅速腐化。我见过团队把“用户登录”“用户修改地址”也做成 REA 事件理由是要做用户行为分析。结果事件类型膨胀到几百种筛选运营数据的时候 SQL 写到崩溃。行为分析该用专门的行为日志和核心经济事件分开存储别混在一个表里。5.3 什么时候别用 REA我不是来劝所有人上 REA 的有些情况下千万别用。你的系统只是个简单 CRUD 后台比如一个小后台管几千条配置数据用 REA 纯属杀鸡用牛刀。只有报表需求没有审计追溯需求传统星型模型加几张事实表好用得多。团队里没有人理解业务事件和业务状态的区别硬上 REA 会导致表结构比业务还复杂。REA 解决的是“业务事实还原、多口径统一、审计追溯”这三个问题。如果你的系统没有这些痛点老老实实用你熟悉的模型别为了追求架构先进给项目挖坑。我在某实验室的信息化项目里就踩过这个坑。当时想借一套先进模型把检测流程全部管起来后来发现整个项目最大价值就是几张统计报表根本不需要事件层的复杂度结果被那张几百字段的事件宽表拖垮了大半年。所以模型选型永远紧跟业务命脉而不是跟着感觉走。6. 迁移与落地避坑指南6.1 从老系统迁移先双写再核对从传统模型迁移到 REA 模型最忌讳一上来就停掉老系统然后切到新系统。你根本无法在一瞬间把存量单据全部变成事件也说不清历史数据里有多少坑。我实际走完的路径是四步老系统照跑原样记录业务。新系统把老系统的每一次新增、变更操作同步解析成 REA 事件。每天跑一次对账任务比对老系统库存、订单金额和新系统事件投影结果。连续一周差异为零才把读写流量切换到新系统老系统保留只读。这个过渡期通常需要两到四周取决于数据量和对账精度。期间最常遇到的差异不是新系统算错而是老系统本来就有历史坏账比如有订单只发货没收款、有库存调整单没有任何原始凭证。遇到这种情况需要业务方一起确认每一笔差异的归属是真实坏账就在迁移脚本里做标记而不是强行把差异抹平。6.2 实际踩过的三个坑第一个坑把“所有操作”都定义为“事件”。我早期在某个模拟项目里把创建订单、修改订单、取消订单、用户催单都建成了事件结果事件类型从一开始的二十多个膨胀到一百多个后面想升级字段连带改了大批代码。后来我们定了规矩REA 事件表里的数据必须是能改变资源状态的经济事实非经济行为的操作记录一律扔到操作日志表。第二个坑让业务方直接填 event_type 字符串。有个项目把事件类型的决定权交给了调用方结果同一个“销售出库”出现了“sale”“SALE”“销售出库”三种写法查询报表时枚举值得在代码里先归并一遍。后来所有事件类型的枚举收口在后端常量类中所有入口只允许传枚举值这种脏数据就绝迹了。第三个坑事件表没有业务唯一键。事件溯源系统重放数据时消息队列偶尔会产生重复消费没有唯一键约束的话库存和收入都会重复计算而且很难追查。给每条事件设计 business_key并用唯一索引兜底是每张事件表必须做的基础设施级约束。6.3 一套可以直接复用的七步落地模板最后我把做过的项目整理成了一个七步模板每次都要走完这七步才开始写表。盘点资源清单列出所有有价值且需要跟踪的资源不限于商品和现金还包括积分、优惠券甚至客户关系。定义事件类型每个资源生命周期里的流入、流出、转换动作各是什么不要带状态只写动作。识别代理哪些个人或组织参与这些事件他们在这个事件里承担什么角色。设计事件表和关联表确定业务时间、记录时间、幂等键、资源与代理的外键。配对互惠关系销售要配收款采购要配付款通过 event_link 表达。建立投影层库存、收入、应收这些查询模型建立在事件投影之上。做数据核对和历史单据核对一遍再和财务对一遍然后灰度切换。这套模板看着不复杂但每一条背后都是惨痛教训换来的。特别是“事件类型”这一条别贪多能合并的尽量合并。宁愿事件描述粗一点、metadata 里放细一点也别让事件类型表膨胀到失控。我个人在实际操作中最受益的一点是REA 逼着我放下了“先设计表和状态再造流程”的惯性转而把“本质事实”放在第一位。状态只是计算结果单据只是凭证资源、事件、代理才是系统真正应该牢牢记住的东西。如果你正在处理跨系统对账、财务口径冲突或者审计追溯难题推荐先把这篇文章里的模型在本地搭一套跑一跑用一周的历史数据做一次投影实验。数据不会骗人模型合不合理跑一遍对账就全暴露了。
