基于REA模型的事件驱动记账系统设计与实践

有段时间我在重构一套业务系统，订单一进来，订单表、发货表、开票表、回款表各记各的，月底财务对账能把人逼疯。财务要的是借贷平衡，业务里只有一堆状态流转，两边死活对不上。后来我换了个思路：不再按“单据类型”建表，而是用 REA 模型——Resource（资源）、Event（事件）、Agent（代理）——把业务和账务统一成一条经济事件流。基于这套思路，我写了个小型项目，代号就叫 rea，正好也是三个核心词的词头拼出来的名字。

这篇文章是 rea 从设计、建表、写代码到上线踩坑的完整复盘。适合正在做进销存、财务模块、订单履约这类系统的开发者，也适合对“业务和账务怎么对齐”这个问题头疼的产品和研发。读完你至少能拿走一套可以直接落地的事件模型，以及我踩出来的坑位地图。

1. 整体设计与思路拆解：为什么非要用 REA 建模

1.1 传统记账模式到底疼在哪

先说我原来的系统长什么样。一张订单，背后有订单表、发货表、开票表、收款表，各表都有自己的状态字段，订单已发货、已开票、已回款是三个互不相干的布尔值。查询“这个订单赚了多少钱”，要把四张表 JOIN 起来，再逐条核对时间和金额。遇到部分发货、部分退款、预付定金抵货款这类情况，每一处都得写专门的 if-else，代码里到处是特例。

月底对账更痛苦。财务导出的应收账款余额，和业务系统里“已发货未收款”的订单金额总和，经常差出几笔。因为发货单和开票单生成的时间点不同，回款又可能拆成好几笔，两边对不上之后只能人工逐单核查，一查就是两三天。这种割裂的根源，不是哪张表设计得不好，而是模型层面没有统一语义：业务系统和财务系统各说各话。

当时我也试过把借贷分录直接落到业务表里，比如订单表加一个“借方科目”“贷方科目”字段。结果更糟：业务上的“销售给客户”和会计上的“借应收账款、贷主营业务收入”根本不是一一对应，中间还隔着成本结转、税费、折扣分摊。把会计语言硬塞进业务结构，只会让两张皮变成三张皮。

1.2 REA 的核心视角：先记录经济事实，再解读成账

REA 的做法和上面完全反过来。它不去管借贷怎么记，只管一件事：经济事实是什么。一次销售，事实是“货从我的库存里少了十箱”，同时“我多了一笔向客户收款的权利”。这两个事实各自都是一个经济事件，前者让库存资源减少，后者让应收账款资源增加。至于“这笔交易赚了多少钱”“要不要确认收入”“按什么税率开票”，都是后续从事实推导出来的解读。

三个要素：Resource（资源）是任何有价值、可用事件改变其存量的经济对象；Event（事件）是导致资源增减的行为，必须在一个时间点发生；Agent（代理）是参与事件的主体，可以是客户、供应商，也可以是内部部门或员工。三者之间有三条核心关系——事件对资源的存量影响叫 stock-flow，交换中一给一得的事件配对叫 duality，代理与事件的关联叫 involvement。概念上就这么简单，真正的工作量在如何把现有业务翻译成这三类对象。

这套模型在会计信息系统理论里已经沉淀了很多年，我最初也是将信将疑，直到自己跑通一单销售后才发现妙处：账务变成了一组可解释、可重放的规则视图，而业务变成了不可变的事件日志。借贷不再需要刻在业务表里，随时可以从事件推导出来。

1.3 项目 rea 的定位与边界

rea 不是完整 ERP，它是一个“事件记账内核”，主要做四件事：维护资源、代理两类主数据并登记事件；保证事件幂等且不可变；提供任一时刻的资源余额查询；按规则把事件派生为会计凭证。我把业务层（订单、发货单这种）放在内核之外，由上层往内核提交事件，再由内核反馈“这单能记，库存够不够、派生凭证是否平”。

技术选型我刻意从简：数据库用了开源的 PostgreSQL，应用层用 Python。没引入消息队列，事件先落库再发通知。原因很实际：记账内核最怕丢事件、重复事件，事务性优先于吞吐量；等到数据量真大到撑不住，再在事件表前面加队列也来得及，不要让架构一开始就复杂。

同时我也明确哪些场景不适合硬套 REA：例如需要复杂成本分摊、合并报表的企业，REA 只能作为底层事实层，报表和成本的“解读层”必须单独设计。这也是我在项目后期才彻底想清楚的，后面会专门讲。

2. 资源、事件、代理：核心概念与数据结构设计

2.1 资源（Resource）：别只想着库存商品

最开始设计 resource 表时，我犯过一个经典错误：只把仓库里的商品当资源。等到想表达“客户还欠我们钱”时，发现没有地方放。REA 里的资源要比“实物”宽得多——现金、商品、原材料是资源，应收账款这种权利是资源，应付账款这种义务也可以建模为资源，只是它的增减方向要特别约定。

我的资源表分了三类：physical（实物）、claim（权利）、obligation（义务）。每个资源有自己的计量单位，商品的单位是箱，应收账款的单位是元。这样设计之后，“卖货”这个动作就变成了两个事件：库存商品流出 10 箱，应收账款流入 500 元。两者的单位不同，但都在同一张事件表里用各自资源对应的计量单位记录。

有一类常见的坑：把“资源价值”直接存进资源表。比如给商品表加一个“最新单价”字段，随时 UPDATE。这在 REA 里不能做，因为资源的价值是随事件变化的，你要的是成交时刻的价格，不是当前的标价。价格、成本这些信息应该挂在事件上，资源表只保存稳定的主数据。我把 unit_price 留在事件侧，后面生成凭证时按事件取价，再也没出现“改了基础资料导致历史账目漂移”的问题。

resource 表结构参考：id、资源编码、名称、资源类型、计量单位。主键之外，资源编码要做唯一约束，因为上层业务需要拿编码去关联。

CREATE TABLE resource ( id BIGSERIAL PRIMARY KEY, code VARCHAR(32) NOT NULL UNIQUE, name VARCHAR(128) NOT NULL, resource_type VARCHAR(16) NOT NULL CHECK (resource_type IN ('physical','claim','obligation')), unit VARCHAR(16) NOT NULL );

2.2 事件（Event）：日志式追加，不可修改

事件表是整套模型的心脏。它的设计原则只有一条：只追加，不改删。任何冲正都通过一个新事件（负向数量）去抵消，而不是把旧事件 UPDATE 掉。这样做换来的东西非常值钱：余额可重算、审计可追溯、派生凭证可复算。如果说 REA 有一种信仰，那就是“记录事实要像历史档案一样严肃”。

每个事件至少需要这些字段：事件类型、资源、数量增减、参与代理、发生时间、幂等键。增减数量我用符号区分：正数代表资源流入，负数代表资源流出。应收账款核销就是一条负向的应收账款事件，库存发货就是一条负向的库存商品事件，语义非常直接。

配套的设计是幂等键。我在 event 表上建了 UNIQUE(ref_id)，ref_id 由上层业务单据号加动作序号拼接。同一条发货单重试提交时，数据库直接拒绝重复的 ref_id，从根上拦住幂等性问题。这个设计后来救了我很多次。

CREATE TABLE economic_event ( id BIGSERIAL PRIMARY KEY, ref_id VARCHAR(64) NOT NULL, event_type VARCHAR(64) NOT NULL, resource_id BIGINT NOT NULL REFERENCES resource(id), delta_qty DECIMAL(18,4) NOT NULL, unit_price DECIMAL(18,4) NOT NULL DEFAULT 0, occurred_at TIMESTAMPTZ NOT NULL, pair_id UUID, UNIQUE (ref_id) ); CREATE INDEX idx_event_resource_time ON economic_event (resource_id, occurred_at);

pair_id 是我用来关联 duality 配对事件的字段。一次销售会产生两个互为镜像的事件（货流出、应收流入），它们共享同一个 pair_id，后续查询“这笔交易对应的完整事件对”特别方便。严格说 REA 理论里 duality 是事件与事件的关系，落到表上就是一个可空的外键或 UUID 组，怎么命名不重要，关键是配对信息不能丢。

2.3 代理（Agent）与多方参与

代理相对简单，我只维护一张 agent 表，类型分 internal（部门/员工）和 external（客户/供应商）。但“谁参与了事件”“以什么身份参与”这两个问题，一开始被我简化成了两个字段：from_agent_id 和 to_agent_id。做简单买卖还行，一遇到三方场景就尴尬——比如一笔退货要同时记录客户、经办销售、仓库验收人，两个字段根本不够。

后来我把参与关系拆成了关联表，事件和代理之间可以有多条记录，每条记录带一个 role。发起方、接收方、审批人、经办人都能表达。这里有一条心得：不要为了省一张表把语义硬塞在固定字段里，参与关系是天然的 many-to-many，老老实实用关联表最稳。

CREATE TABLE economic_event_agent ( event_id BIGINT NOT NULL REFERENCES economic_event(id), agent_id BIGINT NOT NULL REFERENCES agent(id), role VARCHAR(32) NOT NULL, PRIMARY KEY (event_id, agent_id, role) );

3. 实操过程：从零实现一个 REA 记账模块

3.1 建表与初始化约定

先把账套初始化说清楚。我用一个账套表记录每个业务组织的基础设置，比如本位币、成本核算方式；资源表里预置几类默认资源：库存商品、银行存款、应收账款、应付账款。这几类资源在大多数业务里都跑不掉，提前建好，后续再按业务扩展。这里有个容易被忽略的点：库存商品资源要关联“计量单位转换”配置，比如箱和瓶的换算率，在事件层就要把数量统一成基础单位，否则后面算库存时单位混乱。

数据表建好之后，我在资源编码上做了全局约定：以 IC_ 开头是库存类，以 CL_ 开头是权利类，以 OB_ 开头是义务类，以 CA_ 开头是资金类。编码约定看着小，实际对排查问题帮助巨大。比如日志里看到 CA_BANK 就知道是资金类资源，不用翻主数据表去猜。

3.2 核心服务逻辑：事件提交与余额计算

事件提交是唯一写入口。核心函数 record_exchange 接收一组互为 duality 的事件，在一个事务里落库，落完同时触发派生凭证生成。我的伪代码大致是这样：

def record_exchange(session, events, ref_prefix): with session.begin(): for ev in events: ev.ref_id = f"{ref_prefix}:{ev.event_type}" validate_event(session, ev) insert_event(session, ev) if not is_balanced(events): raise ValueError("配对事件不平衡") for ev in events: build_vouchers(session, ev)

validate_event 里主要做三件事：校验事件类型和资源类型匹配，比如 sale_delivery 只能作用于 physical 资源；校验代理角色是否齐全；校验合计平衡，即配对事件的增减金额逻辑成立。校验规则用配置表维护，而不是写死在代码里。后面对账排查时你会发现，规则可视化比代码分支容易核对得多。

余额查询我封装成两个函数。current_stock 给实时查询用，直接对事件表按资源分组求和；period_stock 给报表用，支持指定时间点。一开始我担心 SUM 慢，实际跑下来，几十万事件级别在加了 (resource_id, occurred_at) 索引后毫秒级返回，完全够用，并不需要一开始就上物化视图。

def stock(resource_code, as_of=None): sql = """ SELECT COALESCE(SUM(delta_qty), 0) FROM economic_event e JOIN resource r ON r.id = e.resource_id WHERE r.code = :code """ if as_of: sql += " AND e.occurred_at <= :as_of" return session.execute(sql, {"code": resource_code, "as_of": as_of}).scalar()

3.3 事件到凭证：派生引擎与标识规则库

从事件到借贷分录，我建立了一个派生规则库。每条规则声明：某个事件类型触发哪些科目的借贷，金额如何从事件字段计算。例如：

• sale_delivery：借 主营业务成本，贷 库存商品，金额 = abs(delta_qty) × 成本单价
• claim_receivable：借 应收账款，贷 主营业务收入，金额 = abs(delta_qty) × 成交单价
• cash_receipt：借 银行存款，贷 应收账款，金额 = 事件金额
• claim_settle：核销事件不生成凭证，只更新应收余额口径

我把规则挂在配置表里，事件表加一个 rule_version 字段，每次派生凭证时记录用的是哪个版本的规则。这样万一规则调整，历史凭证仍然知道自己当时是按什么逻辑生成的，重放不会错乱。新增业务类型时，核心代码几乎不用动，只加配置，这是我做了三轮迭代后换来的最大爽点。

3.4 跑一遍完整示例：卖货、收款、结账

拿一套采购入库后销售的场景完整走一遍。假设仓库有 100 箱坚果，成本价 30 元/箱，卖给客户 A 10 箱，售价 50 元/箱，客户随后全额付款。整个过程在 rea 中是这样落的：

第一步，采购入库事件：资源 IC_GOODS，delta_qty=+100，单价 30，agent=供应商，ref_id=PO20250101-01。这一步让库存商品的存量从 0 变 100，同时建立一个应付义务事件：资源 OB_PAYABLE，delta_qty=-3000，表示对供应商的资金流出方向。注意我这里约定资金流出记为负，这个方向约定要在文档里反复强调。

第二步，销售发货事件：资源 IC_GOODS，delta_qty=-10，单价 50，agent=客户。第三步，应收权利事件：资源 CL_RECEIVABLE，delta_qty=+500，agent=客户。这两个事件共享同一个 pair_id，ref_id 分别为 SO20250101-01:sale 和 SO20250101-01:claim。此时按资源汇总，库存余额立刻变成 90 箱，应收余额变成 500 元。

第四步，客户付款：资源 CA_BANK，delta_qty=+500，agent=客户；第五步，核销应收：资源 CL_RECEIVABLE，delta_qty=-500，agent=客户，与第四步共享一个 pair_id。此时银行存款多了 500，应收余额归零。派生凭证层：发货生成借主营业务成本 300（10 箱×30）、贷库存商品 300；应收生成借应收账款 500、贷主营业务收入 500；收款生成借银行存款 500、贷应收账款 500。三张凭证借贷均平。

整个过程里没有任何一处直接写过一个科目的余额。所有科目余额都是从事件重新计算的。月底对账流程从“人工比对总额”变成了“重放事件流，比对余额”，哪一笔对不上，顺着 ref_id 就能定位到原始单据。这就是 REA 带来的最直接收益。

4. 常见问题与排查技巧实录

4.1 库存余额对不上的 4 个根因

上线第一个月，最常被问的就是“库存怎么又多了/少了”。排查下来根因集中在四个地方。第一，事件重复提交，同一张发货单被接口重试落了两条，这个靠 UNIQUE(ref_id) 解决，注意幂等键要把单据号和动作序号都带上。第二，事件被人工 DELETE，运维图省事直接删行，历史余额全乱了，规矩只能是冲销事件，禁止 DELETE。第三，跨时区的时间边界，事件记录的 occurred_at 我统一存 UTC，业务查询时转本地时区，否则 23 点的单会被算到第二天。第四，库存单位不统一，上游下单单据统计，仓库按瓶出库，换算漏了，后来我在入库事件就把数量统一折算成基础单位。

排查方法也有技巧。不要一上来翻所有流水，先看这个资源当前余额和上一期快照的差值，再倒推时间窗口内的事件列表，逐条对比。因为 REA 的余额是可重算的，所以定位到可疑事件后，可以把它从事件流里“逻辑剔除”再算一遍余额，如果和期望一致，基本就锁定元凶了。

4.2 派生凭证不平：规则和事实脱节

凭证不平的案例几乎都出在规则库和业务事实脱节。最典型的是部分退款：业务上客户退货 3 箱，但应收核销时如果直接用 -3×50 的事件去冲，和原应收的匹配关系就丢了，账上会出现负收入。正确做法是把“退货入库”和“应收冲销”当成两个独立事件，且各带各的 ref_id，金额用原数量乘原单价，完全对称地冲减。我后来在规则库加了一条硬校验：冲销事件的 ref_id 必须关联到被冲销事件，没有关联的一律拒绝。

另一个坑是含税价和不含税价。事件上记录的是成交单价，但开票和收入确认要按不含税价，如果事件里只存一个价，派生规则没法区分。我最后在事件上加了 price_type 字段，明确成交价是含税还是不含税，派生时按规则换算。结论是：事件字段要尽量保留业务原貌，不要把“为了做账而算出来的中间量”覆盖掉原始事实。

4.3 事件表膨胀与慢查询

事件表只增不改，一年下来几百万行很正常。我的处理是：保留一张独立的余额快照表，每天凌晨按资源加账套聚合一次当日 delta，查询历史余额先取快照，再补算当天增量；事件明细只用于审计和追溯。这样报表查询从扫全表变成扫当天，速度提升非常明显。注意快照表也是可重算的——任何时候都能从事件表全量重建，这一点保证快照出问题时有退路。

索引上，除了 (resource_id, occurred_at) 外，给 agent_id 也加一个索引，应收账款的余额按客户维度统计时会用到。如果未来要按 pair_id 查事件对，再建 pair_id 索引。索引别贪多，事件表是写频繁的表，索引太多会影响落库性能。

4.4 踩坑速查表

5. 这套模型的扩展与适用边界

5.1 和事件溯源的关系

做过事件溯源的同学看到这里应该会心一笑：event 表本身就是天然的事实源。rea 里的事件记录一旦落库，就可以作为对外发布的消息源，下游系统订阅事件做履约、风控、报表，而不是反向去查业务单据。区别在于事件溯源通常关心状态的重建，REA 更关心经济含义，两者可以结合：把 REA 事件作为领域事件的骨架，带业务字段的通用事件做扩展，既保证财务口径，又保留业务灵活性。

另外，前后端如果都按“提交事件”而非“提交状态变更”的语义交互，接口设计会清爽很多。比如“确认收货”这个动作，前端提交的是“签收事件”，后端只负责落一条事件并返回新余额，而不是去 update 一个订单状态字段。整个系统的状态流转，都变成对事件流的投影。

5.2 什么时候不要用 REA

我在项目里踩过最贵的一课，是在一个其实很简单的 CRUD 项目中强行引入 REA。当时以为“面向未来”，结果为了一个没有交易复杂度的系统维护资源、事件、规则三套维护入口，反而拖慢交付。REA 解决的是“业务事实与财务解读分裂”的问题，如果系统根本没有财务和库存账，纯粹的信息登记，用普通表更合适。

高并发场景也要谨慎。秒杀场景下库存余额用 SUM 算会放大热点，正确做法是先用缓存预扣，再异步落 REA 事件。事件表只是事实层，不等同于所有实时读都必须直接查它。

成熟企业的合并报表、税务合规通常已经被稳定的财务系统覆盖，重构核心总账风险极大。REA 更适合作为新业务模块的底座，或者在拆分单体系统时对账务域重新建模，而不是去替换一个已经稳定运行多年的总账核心。

5.3 一点点个人体会

rea 这个项目做完后，我最大的感受不是“建模理论有多高级”，而是“业务和财务终于说同一种语言了”。研发不用再维护两套口径，产品讲“客户付款”的时候，开发知道那是两个事件、两类资源、一套派生规则的事。这种一致性带来的效率，比任何代码优化都明显。

如果你想在自己系统里尝试，我的建议是别一口吃成胖子：先挑“库存 + 应收应付”这块最痛的场景，把资源、事件、代理三张表建起来，跑通一个销售-收款闭环，剩下的业务类型慢慢加。边做边体会，你自然知道哪些地方需要灵活、哪些地方值得坚持不可变。至少对我而言，下一次再碰到财务和业务对不上的系统，我会第一时间先画事件图，而不是急着拆表。