如果你也遇到过这种情况业务代码写得爽月底一对账就头大订单状态、财务流水、库存变更三套数据各唱各的调那这篇笔记大概率能帮到你。Rea 这个项目名短到第一次看像拼写错误但它其实是 Resource-Event-Agent 三个词的缩写。很多会计信息系统教材和供应链系统设计里都会提到 REA 模型我把它作为内部项目的代号做了一个中间事件层专门处理“业务发生了账该怎么实时跟着反映”这个老难题。这篇文章会从项目选型思路讲起再给出一套可直接抄作业的数据模型设计然后用一个真实销售订单的案例演示事件流是怎么落库的最后整理我在这个项目里踩过的坑和排查经验。适合后端开发、数据工程师、解决方案架构师以及任何对“可追溯账务”感兴趣的人参考。1. 项目概览Rea 为什么不用借贷分录而用资源事件代理项目立项时团队最大的痛点不是写不出业务代码而是没法回答一个看似简单的问题“现在我们仓库还剩多少货每一单赚了多少这笔应收款还挂着多久”手机订单、采购入库、退款、赠品、运费分摊……每个环节都在业务系统里记录了一次但记录的口径完全不同。订单模块记状态仓储模块记数量财务模块记借贷月底要财务和运营对账只能靠人肉拉表格比对。引入 Rea 的初衷就是统一口径。REA 模型最早是会计信息领域提出的一套语义模型核心是三个基本概念资源Resource企业所控制的有价值的东西库存商品、现金、应收账款、服务时长都算。事件Event让资源数量、金额、归属发生变化的经济活动比如出库、收款、退货。代理人Agent参与事件的人或组织比如客户、供应商、仓库员。这套模型把“记账”从传统会计的借贷分录中解放出来。传统借贷强调的是“钱从哪来、到哪去”本质上是把业务动作转译成财务凭证而 REA 强调的是“谁在什么时间、什么资源上做了什么”业务事件本身就是账。这样做的好处是显而易见的所有部门共享同一套事实来源财务凭证可以由事件推导出来而不是反过来。项目中我坚持用 REA 而不是直接做一套财务总账表是因为业务系统每天产生的订单、发货、回款本身就是最可信的事实。只要把事件记录完整、关系描述清楚“账”是可以被计算出来的而不需要人为去登记借贷。团队不再需要关心“这笔该记借方还是贷方”只需要回答“哪个代理人对哪个资源做了事件”剩下的账就是查询和聚合的事。Rea 项目定位也非常克制不做一个新 ERP不改原有的业务前端只在业务库和报表分析之间插入一套事件化的模型层。业务系统照常运行把关键经济动作异步写入事件表分析、对账、审计直接读 Rea 提供的事件流。边界清晰改造量小是这套方案能被业务部门接受的重要原因。1.1 为什么传统方案解决不了对账问题原业务系统的数据流是这样的订单模块保存订单状态仓储模块保存发货单财务模块保存付款凭证。表面上每套数据都在记录同一笔销售但时间点不同字段含义不同。订单状态是“已发货”财务流水可能还没有回款仓储已经出库财务可能还在等发票。各系统之间靠一个订单号关联关联不到的记录就变成对账差异。REA 做了一个关键转换把所有业务动作统一成事件每个事件都带时间、资源、代理人和方向。业务上关心“这笔订单还在途”查询订单状态表财务上关心“钱到账没有”查询现金事件仓库关心“货还剩多少”查询库存事件的累计。同一笔业务动作对业务是状态更新对 Rea 是一次事件写入不需要多个系统各自维护一套口径。1.2 适用范围什么业务适合用 REA不是说所有系统都应该改用 REA。用到这个模型最合适的是资源流转频繁、需要对账、要强追溯的业务比如电商、供应链、仓储物流、企业服务订阅计费。纯内容型产品或者弱逻辑流程比如文章管理、短消息发送事件模型反而会增加复杂度。Rea 在项目里只覆盖了商品、库存、订单、应收应付、回款退款这几个域其他不涉及资源变更的模块一概不碰这也是项目能小步快跑的原因。2. 数据模型落地三张表把资源、事件、代理装进数据库模型再漂亮最后都要落到表结构上。我在 Rea 项目里的核心表非常克制没有设计一张巨大的“流水表”而是把资源、代理、事件分成三层再用一张关系表把事件和事件之间的因果链串起来。下面这套 DDL 是项目里精简后的版本去掉了租户和权限字段保留了最关键的部分可以直接贴合业务改造使用。2.1 资源表 resource只描述资源本身不存余额create table resource ( id bigserial primary key, resource_type varchar(20) not null, code varchar(64) not null, name varchar(128) not null, unit varchar(20) not null, value_currency varchar(3) not null default CNY, effective_from timestamptz not null, effective_to timestamptz not null default infinity ); create unique index uk_resource_code_type on resource(resource_type, code);资源表记录的是“存在性定义”比如 SKU、现金科目、应收科目、服务工时包。我刻意没有在这里放任何余额字段。库存还有多少、现金还剩多少这些是结果不是数据。结果放资源表里一旦事件和结果不一致你就分不清谁是基准。正确的做法是让所有余额通过事件计算得到资源表只保证资源的身份稳定。一个经常被忽略点资源不是主数据资源更像“账本上的科目”同一个商品代码如果因为采购批次不同导致价值属性不同可以用不同资源实例来表示而不是在资源表里塞一堆可变属性。这样可以避免后面对账时出现数量能对上、金额对不上的尴尬。2.2 代理表 agent不只是用户而是所有责任主体create table agent ( id bigserial primary key, agent_type varchar(20) not null, code varchar(64) not null, name varchar(128) not null, external_ref varchar(64) ); create unique index uk_agent_code_type on agent(agent_type, code);agent 表里既放客户、供应商也放内部员工、门店。一开始团队有人提议复用现有用户表但我否了这个想法。原因很简单Rea 中的代理人不等于系统登录用户。一个客户主体可能对应多个登录账号一个仓库操作员可能离职删除还有像“自动退款流程”这种没有真实操作人但有责任主体的事件用户表根本承载不了。代理表只记录经济责任主体业务系统的用户信息通过 external_ref 关联。这样后续做“某个客户所有事件流”的查询会非常顺畅不需要 join 业务用户表再过滤各种异常状态。2.3 事件表 economic_event事件是事实不是分录事件表是整个模型的心脏。我同样不建议把它叫 transaction因为很容易让人往“会计分录”方向理解。create table economic_event ( id bigserial primary key, event_type varchar(40) not null, occurred_at timestamptz not null, resource_id bigint not null references resource(id), agent_id bigint not null references agent(id), contract_id bigint not null, quantity numeric(18,4) not null default 0, amount numeric(18,4) not null default 0, unit_price numeric(18,4) not null default 0, note text, created_at timestamptz not null default now(), unique (contract_id, event_type, resource_id, agent_id) ); create index idx_event_resource_time on economic_event(resource_id, occurred_at); create index idx_event_agent_time on economic_event(agent_id, occurred_at);事件表字段的含义是统一的谁agent_id在何时occurred_at对什么资源resource_id做了什么event_type数量变化是多少quantity金额变化是多少amount。quantity 用正负号表示方向不区分 inflow/outflow 字段。这里每个事件都是“单腿事件”它只描述一个资源的一次变动。不要试图把两条资源变动塞进一条记录。库存出库和现金到账是两件独立的事虽然它们逻辑上关联但写成一行会造成两个资源变动耦合在一起后续很难追溯。2.4 事件关系表 event_link把交换关系显式表达出来REA 模型里有一个核心概念叫双重性关系duality它表示“一个资源流出事件和一个资源流入事件共同构成一次经济交换”。我把它落地成了一张独立的关系表create table event_link ( id bigserial primary key, source_event_id bigint not null references economic_event(id), target_event_id bigint not null references economic_event(id), link_type varchar(20) not null default exchange, contract_id bigint not null, unique(source_event_id, target_event_id) );为什么要把事件关系单独建表因为如果不明确记录“哪次库存出库对应哪次现金流入”后续对账根本无法自动化。虽然可以通过 contract_id 把一批事件凑在一起但 contract_id 只能告诉你这些事件属于同一单据无法告诉你事件之间的因果关系。手工核对的时候还是要靠人一条条看。event_link 表解决了“完整性”问题一次销售事件的库存出库必须关联到对应的现金或应收事件否则这笔业务在对账时就是断链的。项目里每天晚上会有校验任务专门找“有出库事件但没有对应收款事件”的孤灵魂这也是我们在上线后能够快速发现订单漏发通知问题的关键。3. 实操实录把一笔销售订单改写成事件流水看完了 DDL接下来演示一个完整案例。这个案例非常典型客户 A 下单购买 2 件商品商品总价 4500 元仓库发货财务收款 4500 元月末发现其中一件有质量问题退款 2250 元。3.1 先把业务过程翻译成事件目录做这个项目时我的第一件事不是建表而是约上运营和财务把销售流程从头到尾捋了一遍定义清楚了每类事件业含义。业务动作事件类型变更资源数量/金额变化代理人客户下单sales_order_created商品资源无资源变化仅记录契约客户仓库发货stock_out库存商品quantity -2仓库员确认应收receivable_in应收账款amount 4500客户客户付款cash_in现金amount 4500客户退货退款stock_in库存商品quantity 1客户退款挂账cash_out现金amount -2250客户你会发现 REA 里下单本身不是资源事件它只是一个“未发生事件”的契约。真正的资源变动从发货和确认应收开始。这也是开始时团队最大的认知转变点业务上的“订单状态”和资源账上的“事件”是两回事。订单只是承诺事件才是事实。3.2 写入事件与防重控制项目里我封装了一个函数 create_event专门负责事件写入。核心逻辑是先查合同号 事件类型是否已存在存在就返回旧事件 id不存在才插入。这个做法的目的是保证消息异步重放时不产生重复事件。insert into economic_event( event_type, occurred_at, resource_id, agent_id, contract_id, quantity, amount, unit_price, note ) values( stock_out, now(), 10001, 20001, 50001, -2, -4500, 2250, 销售订单发货 50001 ) on conflict (contract_id, event_type, resource_id, agent_id) do nothing;这条 SQL 不会认为发货事件“使库存数量变化 -2”很奇怪因为项目中把所有资源的变动方向统一放在 quantity 和 amount 的符号里。库存出库 quantity 就是负数退款收回来 quantity 就是正数写逻辑时心智负担小很多。接着创建对应应收事件insert into economic_event( event_type, occurred_at, resource_id, agent_id, contract_id, quantity, amount, unit_price, note ) values( receivable_in, now(), 10002, 20001, 50001, 0, 4500, 2250, 销售发货后确认应收 50001 ) on conflict (contract_id, event_type, resource_id, agent_id) do nothing;两条事件都写入成功后再在 event_link 里写关系insert into event_link(source_event_id, target_event_id, link_type, contract_id) values(200001, 300001, exchange, 50001);这个关联关系是后续自动对账的基础。开发时一定要把 source 和 target 的命名讲清楚我项目里踩过一次很尴尬的坑把 source 事件存成了现金流入事件结果对账脚本无论如何都查不出断链最后还是靠手工看数据才发现方向反了。3.3 用 SQL 直接算出实时库存和应收余额事件流水全部写入后余额本身就是查询结果。例如计算某时间点库存余额select resource_id, sum(case when event_type stock_in then quantity when event_type stock_out then -quantity else 0 end) as current_stock from economic_event where occurred_at :check_time group by resource_id;这串 SQL 不需要任何 order by不需要去重逻辑就是“把 resource_id 相关的所有进库事件数量加起来减去所有出库事件数量”。发布上线后运营第一次实时看到库存数据时说了句“怎么每笔变动都能查得和流水账一样”这句话让团队都觉得值了。应收账龄分析也同理只要把资源切到应收账款统计所有未核销的 receivable_in 事件再关联 event_link 找到应收对应的现金到账事件就能算出每笔应收挂了多少天。原来财务手工半小时做到的事现在让一个 Cron 脚本跑一次准确率还更高。4. 常见问题与排查技巧实录任何模型到实战里都不可能一次顺利。Rea 项目从设计到上线前后经历了不少波折。我把几个最容易踩的坑和排查手段整理成清单供大家参考。4.1 事件写入后就不能改那写错了怎么办这是团队新人问得最多的问题。事件是既成事实订单出库多写了数量总不能直接 update 事件把数量改成正确的那样对账链条就断了审计也无法追溯。我的处理方式是写一个相反方向的冲正事件。比如库存出库误写成 -5正确的应该是 -3那就补一笔 stock_in 数量 2 的冲正事件。这两笔事件在账上都保留余额自然变成正确的 -3同时原始的错误也留下了痕迹。有人觉得这样会让库存流水变得很乱但账务系统的规则就是“痕迹大于美观”。事件表里的脏数据不是错误它是曾经发生过的过程。审计、复盘的时候过程的完整性比结果的干净更重要。4.2 对账差异大概率出在时间边界上项目上线第二周运营反馈为什么上午 10 点的库存余额和仓库系统差了 5 件我在本地跑 SQL 怎么看都对。后来发现不是事件逻辑错了而是时区问题。仓库系统用的是本地时间Rea 统一使用 UTC 存储查询报表时按业务时区转换。排查时不要只盯着 SQL先确认两个系统的“时间切面”一致。对账必须固定一个统一口径所有事件 recorded 时间基于 UTC所有报表展示用 Asia/Shanghai 时间如果还差异再查事件写入延迟。事件流系统常见的对不上账百分之七十是时间切面或时区边界问题剩下百分之三十才是事件缺失。4.3 事件表膨胀很快查询越来越慢怎么办Rea 上线三个月后事件表已经破了千万行。基础查询还能撑住但带 event_link join 的应收账龄分析明显变慢。解决方案分两步事件表按月分区物化每日余额快照。-- 按月分区示例简化 create table economic_event_2025_04 partition of economic_event for values from (2025-04-01) to (2025-05-01);日常实时查询仍然查明细事件报表类高频查询则读取每日快照。快照只保存每天最后一个业务时点的资源余额既能满足大多数场景又能大幅减少聚合时间。使用物化快照的家庭要根据自己的查询模式设定快照频率不要一开始就做成实时物化视图。4.4 常见问题速查表现场现象优先排查方向修复办法对账数量差异事件是否缺失或重复按 contract_id 全链路排查事件流金额平但数量不平资源单位/规格换算不一致检查 resource 表 unit 与业务单位映射应收一直挂着未核销event_link 是否缺失查是否有 receivable_in 无 link 关联同一事件被重复统计唯一约束是否有冲突确认 contract_id 唯一索引是否生效时间切面不一致时区/延迟统一 UTC 存储报表单独转业务时区这四个坑解决完Rea 的稳定性就会提升非常多。如果你也要落地事件溯源模型建议先准备好上面这张排查表遇到问题才不至于手忙脚轮。5. 项目复盘Rea 上线后的收益和后续优化方向最后聊聊这个项目上线后我观察到的真实收益和后续优化方向。Rea 带来的第一个变化是“对账从月结变为随时可查”。过去财务每月月底花两天时间拉订单清单、银行流水、仓库出入库单做 excel 匹配现在直接看一张财务报表按时间、客户、事件类型筛选即可。财务团队从“在 excel 里对账”变成了“在系统里看账”这个体验升级完全改变了他们对我们技术团队的态度。第二个变化是业务术语统一了。此前“销售出库”在订单系统里是“已完成”在仓储系统里是“待出库”在财务系统里是“库存减少”。现在所有人都统一称“stock_out 事件”跨团队开会不会再出现鸡同鸭讲。我没想到一个数据模型能把沟通成本降下来这一点确实超出预期。影响范围方面Rea 后续还能沿两个方向扩展一个是把 contract 实体加得更完整支持复杂分期、采购订单、服务合同另一个是支持基于事件流的审计报告自动生成。实际从我的经验看最推荐优先做后者因为财务审计对事件追溯的需求是刚性的投入产出比非常高。如果让我重新做一遍 Rea我会在一开始就给事件表加一个聚合 ID把关联事件组成一个更大的“业务流”概念而不是只靠 event_link 两两关联。现在的两两关系在做多次部分退款时会额外增加一些查询复杂度一个聚合根 ID 会让全链路追踪更顺手。但总的来说REA 这套“用事件本身当账”的思路确实让我对业务建模有了完全不同的认知。以后再做任何带资源流转的系统我第一反应一定先把事件目录清理干净再谈页面和报表。