看到REA这三个字母懂行的人会先想到资源、事件、主体Resource-Event-Agent而不是某个框架或库名。这套模型最早是给会计信息系统做业务建模用的但我发现它解决的不只是记账问题电商、供应链、积分、钱包这些系统里最烦人的状态不同步本质上都是因为把当前状态当成了事实。这篇我结合在一个订单和库存反复对不上的项目里踩过的坑把 REA 的建模思路和落地表结构一次讲清楚适合正在做订单、库存、账务、积分这类业务的后端开发、架构师和数据产品经理。如果你只是想找一个能直接抄作业的表结构可以直接跳到第3章如果你想弄明白为什么改状态字段这种最顺手的设计会在半年后变成事故源头建议从第1章往下读。我的结论先放在这状态不是数据状态是事件的投影。这句话理解了整个 REA 模型就通了。1. 为什么当前状态式建表会让业务系统越改越乱1.1 我栽过的跟头状态字段引发的连锁事故之前做过一个零售订单系统早期设计非常正常订单表里放一个status字段从待支付到已支付、已发货、已完成库存表直接存当前剩余数量用户钱包表直接存当前余额。所有业务逻辑都围绕判断当前状态 修改当前状态展开。刚开始数据量小一切岁月静好。等促销、退款、分批发货、客服人工改单开始出现问题就来了。第一个事故发生在退款流程用户申请退款代码把订单状态改成了已退款也把钱包余额加回去了但库存表没有回补。为什么因为退款逻辑关注的只是订单状态它压根不知道这个订单对应哪几个库存流水。第二个事故是运营手工把订单状态改成已完成实际上仓库根本没发货数据凭空丢失了事实依据。这些问题的根源不是某一段代码写错了而是整个建模方式有问题status字段是当前值不是一个业务事实。改当前值不留任何可审计的痕迹一旦多个功能模块都要改动这个值状态机就会以指数级膨胀。今天加一个部分发货明天加一个售后中后天再加一个风控冻结每个状态都得考虑前一状态、后一状态、谁可以改、改完要不要触发回调。系统不爆炸才怪。1.2 REA 的第一性原理状态是事件的投影REA 模型给出的回答很简单不要存现在是什么状态只存历史上发生了什么事件。三个字母分别是Resource资源有价值、可计量、可被组织控制的东西比如现金、库存商品、应收账款。Event事件导致资源增加或减少的经济动作比如收款、发货、入库、退货。Agent主体参与事件的人、部门或组织比如客户、仓库操作员、供应商。它们之间的关系也很好理解一个主体在某个时间点发起或参与了某个事件这个事件改变了某种资源的数量。所有当前状态比如库存剩多少、客户还欠多少钱、订单走到哪一步都不是独立存储的事实而是把事件按时间汇总之后算出来的结果。这跟银行账户是一个道理流水表才是事实余额表只是把流水加总后的投影。银行不会因为余额显示异常就去改流水而是重新计算余额。REA 就是把这种思维方式从金融领域搬到了更宽泛的业务系统建模里。在这个模型里订单状态不是字段而是有没有支付事件、有没有发货事件、有没有退货事件的逻辑组合。库存也不是字段而是入库事件数量减出库事件数量的聚合结果。谁想问为什么都能顺着事件追溯回去。2. REA 三类核心对象拆解资源、事件、主体怎么选2.1 资源有价值、可计量、可控制三者缺一不可很多人在建资源表时会把资源等同于商品或钱然后就开始纠结优惠券算不算、服务算不算、客户信任算不算。我的判断标准只有三个缺一个都不建模成资源有价值直接或间接带来经济利益。现金有价值库存商品有价值应收账款有价值积分有价值可计量可以用数量或金额量化。计量单位不一定是件还可以是小时、次数、公里、克可控制企业或系统对其有支配权或管理权。客户满意度虽然重要但你既不能准确计量也不能单方面控制它所以不适合做资源。服务类业务也适用。比如一个咨询项目计量单位是小时一次云服务调用计量单位是次。只要你能定义单位就能把它放进资源表。实战中我会给资源表加上类型字段create table resource ( id bigint primary key, name varchar(100) not null, unit varchar(20) not null, -- 件、小时、元、次 resource_type varchar(30) not null, -- inventory / cash / receivable / point is_monetary boolean not null default false );货币性资源和非货币性资源的处理方式不太一样。现金、应收账款这类金额资源事件里记录的是金额库存、积分这类资源事件里记录的是数量可能还需要换算金额。这样拆开后续做总账和业务台账时会清爽很多。2.2 事件真正能改写资源账目的原子动作事件是整个 REA 模型里最重要也最容易搞错的对象。很多人会把业务操作直接当成事件比如用户登录客服改备注这些操作不改变任何资源的经济价值不该进事件表。我判断一个动作能不能成为经济事件只看四点是否发生在某个时间点而不是持续模糊的时间段是否明确地增加或减少了某种资源是否有可计量的数量或金额是否至少涉及一个主体。比如下单本身不是经济事件因为商品还没有转移、钱还没付它只是产生了一个承诺支付发货退货入库才是经济事件。如果按这个标准绝大多数状态字段问题都会暴露出来你根本没有支付事件凭什么把订单改成已支付事件之间还存在配对关系。一个典型的交易我的资源减少必然伴随着另一个资源的增加REA 里叫事件对偶duality。比如发货库存商品减少同时应收账款增加收款应收账款减少现金增加。后面第3章的案例会具体演示这种配对。2.3 主体谁有权操作比是谁更重要主体可能是我实际项目里最容易被忽略的一块。很多系统的操作记录只有user_id但user_id代表的是登录账号它无法回答两个关键问题这个人当时代表哪个组织他有没有权限做这个操作采购场景特别明显下单人是一个采购专员付款方是公司收货地址是某个门店仓库。如果事件表里只记录了下单人的user_id后面的对账、审计、责任追溯全都会卡住。所以在事件表里我至少会区分两个主体字段操作主体谁发起的动作和对手主体和谁发生的交易。对于内部授权关系可以单独建模也可以简化成一张主体关系表。原则是事件记录必须回答是谁、代表谁、对谁三个问题否则它就不是一个完整的事实。3. 用一个商城订单案例把 REA 完整落成表结构3.1 从下单到收款一条订单拆成哪几个经济事件用一个最常见的场景某客户在线买一件衣服价格 100 元优惠券抵扣 10 元实际支付 90 元仓库发货客户收货。按 REA 的拆法这条订单不是一条记录而是几个独立事件支付事件客户的钱包或银行账户减少 90 元平台钱包或待清算资金增加 90 元发货事件库存商品减少 1 件同时产生一笔应收账款如果发货时还没收款或确认资金入账如果已经收款后续收款核销事件如果发货时挂的是应收账款收到钱后再把应收账款清零、现金增加。这里有一个关键认知收入不是资源也不是事件。收入是发货事件和收款事件共同作用的统计结果。你不要在系统里专门插入一个收入增加事件那样会造成事实重复对账时极易出现两边数字对不上。REA 的做法是只记录资源变化收入报表通过事件聚合算出来。下单这个动作我通常会留在承诺层也就是继续保留订单头、订单行但订单行只表示承诺要交付的商品。实际库存变化必须来自发货事件。这样承诺量和实际量就分开了后面做部分履约会非常自然。3.2 表结构怎么设计一张事件表撑起库存和应收最小可用的落地方案就是一张扁平的经济事件表。每个事件记录一笔资源增减可以满足的库存、余额、应收账款查询。create table economic_event ( id bigint primary key, event_type varchar(50) not null, -- payment / shipment / return / adjustment occurred_at timestamptz not null, resource_id bigint not null, direction varchar(10) not null, -- in / out quantity numeric(18,4) not null, unit_price numeric(18,4) not null, base_amount numeric(18,4) not null, original_amount numeric(18,4) not null, currency varchar(10) not null, rate_to_base numeric(18,6) not null, agent_id bigint not null, -- 操作主体 counterparty_id bigint not null, -- 对手主体 ref_document varchar(64) not null, -- 关联订单号/支付流水号 ref_event_id bigint null, -- 关联事件如退货指向原发货 created_at timestamptz not null default now() ); create index idx_event_resource_time on economic_event(resource_id, occurred_at); create unique index uq_event_ref on economic_event(ref_document);这个表能解决大部分问题但它有一个明显不足一个支付事件既影响应收账款又影响现金如果只建一行就得把两个资源塞进一条记录语义会很拧巴。所以我在实际项目中更推荐事件头 事件分录的结构类似记账凭证和分录的关系create table economic_event ( id bigint primary key, event_type varchar(50) not null, occurred_at timestamptz not null, agent_id bigint not null, counterparty_id bigint not null, ref_document varchar(64) not null ); create table event_entry ( id bigint primary key, event_id bigint not null references economic_event(id), resource_id bigint not null, direction varchar(10) not null, quantity numeric(18,4) not null, unit_price numeric(18,4) not null, base_amount numeric(18,4) not null, currency varchar(10) not null, rate_to_base numeric(18,6) not null );一个支付事件下挂两条分录应收账款减少 90现金增加 90。一个发货事件下挂两条分录库存减少 1 件应收账款增加 90。每次对账都可以从事件重新推导永远不会出现钱包余额加了但库存没回补的情况因为所有改动都发生在同一套事件机制里。3.3 余额和库存怎么算一条 SQL 复现账目有了事件表当前库存就是所有库存资源的流入减流出select resource_id, sum(case when direction in then quantity else -quantity end) as current_balance from event_entry where occurred_at now() group by resource_id;某个客户当前还欠多少钱也就是应收账款余额可以这样算select counterparty_id, sum(case when direction in then base_amount else -base_amount end) as receivable_balance from event_entry where resource_id 1001 -- 应收账款资源ID group by counterparty_id;这两条 SQL 看起来很简单但它的意义是任何时刻的余额都可以用同一套事件重算出来。审计时不需要相信某个当前值字段只需要把事件重新加一遍。这也让我在排查问题时节省了大量时间——某个数字不对不再去猜哪张表被谁改过直接按事件筛选很快就能定位到是哪条流水写错了。3.4 价格、折扣、税费这种附加属性放哪里这是我在项目里被问得最多的问题订单有商品原价 100优惠券抵扣 10税费 5实付 90这些字段该塞哪如果用的是扁平事件表最省事的办法是把单价记成 90把原价和优惠折扣放在订单表里供展示。但这样一做审计链就断了一半你无法从事件表看出这 90 元是由 100 元商品、-10 元折扣、0 元税组成的后续如果要对折扣单独分析就得去 join 订单表。更干净的做法是把折扣和税费也建模成资源分录。一个发货事件可以有三条分录库存商品 out数量 1金额 100折扣资源 in负向调整金额 -10税费资源 in金额 5。这样收入报表、折扣费用报表、税费报表都可以直接看事件分录不用再从 UI 层硬挖数据。缺点是表行数会增加事件写入会变复杂。如果业务对折扣和税费没有独立审计要求也可以妥协事件分录只记最终成交金额订单行保留原始明细。取舍的标准只有一个——将来会不会有人拿着这个数据去问为什么是这个数如果会就别省。4. 边界场景怎么保持模型干净退货、部分履约、多币种4.1 退货不是负数流水而是独立反向事件我第一次用 REA 建模退货时也想走捷径既然发货是库存 out 1退货就记库存 in -1等于把原事件冲平。后来发现这是一个典型的坑。如果退货以负数数量的形式并入原发货事件你的领导或审计会看到一条数量为负的出库记录它到底是系统异常、数据错误还是真的退货完全不可判定。而且退货本身还有验收、质检、是否重新入库、退款金额是多少这些独立信息把它们揉在一个旧事件里等于把所有后续业务都锁死在历史数据上。正确姿势是创建一个新的退货事件它有自己的事件 ID、时间、操作主体ref_event_id指向原发货事件。分录如下库存商品 in数量 1应收账款或现金 out/调整金额 90。原发货事件完全不动。查询原发货量仍然是 1查询退货量也能单独统计出来。这种追加不修改的模式才符合事件不可变原则也方便日后做售后分析、退款结算和库存效期管理。4.2 部分履约和分批发货让状态自然推导订单买了 3 件商品仓库先发了 2 件剩 1 件等补货后再发。传统状态机方案里你得新增一个部分发货状态然后开始处理部分发货到已发货之间的各种组合。REA 方案完全没有这个状态。订单行记录的是承诺数量 3发货事件记录的是实际出库 2过几天再补一条发货事件出库 1。任何时候想知道这个订单发完了没有只需要比较承诺数量和发货事件的汇总数量select ol.order_id, sum(ol.quantity) as ordered_qty, coalesce(sum(case when ee.direction out then ee.quantity else 0 end), 0) as shipped_qty from order_line ol left join event_entry ee on ee.ref_document ol.order_line_doc where ol.order_id 12345 group by ol.order_id;这里的关键是订单履行状态不是一个字段而是承诺量减实际量的计算结果。发货不足就继续待履约全部发完自然就是已完成。需要往状态机里加的状态在这里全都消失了。这个设计对供应链里的分批到货、部分缺货、多次售后特别实用。4.3 多币种与汇率把汇率锁进事件时间点做跨境业务时最容易出现的问题是金额漂移。假设订单发生时美元兑人民币汇率是 7.1事件分录里记了 $100 对应 ¥710一个月后汇率变成 7.3如果资产余额表里的值被定期重估那你翻历史报表时会发现上个月的收入数字跟着当前汇率变了这显然不可接受。REA 的解决思路是汇率是事件发生时刻的事实不是余额表的属性。每条分录必须同时记录原始币种金额、原始币种、汇率和折算后的基准币种金额。基准币种金额在事件写入时锁定不做自动重算。期末如果需要按最新汇率重估货币性资产可以作为一个独立的重估事件写入分录方向是汇兑损益调整。这样既保持了历史事件原貌又满足了财务上按期末汇率披露的需求。两点必须同时存在缺一个都会在未来某天对不上账。4.4 幂等与并发防止账目重复入账事件表是追加式的但这不代表不会重复。支付渠道回调重试、用户重复点击提交、消息队列重复消费都可能让同一个业务动作产生两条事件分录。所以我对事件表有一个硬性要求业务原始凭证号必须唯一。在上面的表结构里ref_document字段承载的就是这个幂等键。支付回调时用支付渠道返回的流水号作为ref_document并建唯一索引。如果来了重复回调数据库会直接拒绝第二次插入事件就不会写重。并发方面两个仓库操作员同时出库同一资源时事件表本身很难做简单的行锁约束。我的做法是写入事件前先对资源 ID 做一次聚合校验比如库存是否够用在强一致性要求高的场景可以给资源记录加乐观锁版本号事件写入时校验版本号。普通业务量下这种程度的保护已经够用了。5. 渐进落地策略不推翻系统也能用上 REA5.1 事件溯源是存储机制REA 是业务语义很多人会把 REA 和事件溯源Event Sourcing混为一谈。它们其实是两层的概念事件溯源说的是怎么存REA 说的是怎么对业务建模。事件溯源要求系统只追加事件日志不直接修改当前状态REA 告诉这些事件应该长什么样必须包含资源、方向、数量、金额、主体、对手主体、时间并且状态全部可以投影计算。你可以只做事件溯源而不遵循 REA那样事件虽然不可变但每个团队可能各写各的事件类型五花八门最后还得靠人脑去对语义。也可以只用 REA 的概念设计关系表不用事件溯源那一整套基础设施。我倾向于两者结合存储层用只追加的事件表业务语义层用 REA 的三类对象来约束事件结构。这样既保证了可追溯又避免了什么都能塞事件带来的混乱。5.2 查询走投影为库存和账单准备读模型有人会质疑如果所有查询都实时聚合事件表量一大肯定扛不住。这个担心有道理但解决方案不是回到存状态字段而是建投影表也就是读模型。投影表就是一个缓存起来的统计数据。比如inventory_snapshot按资源维度存当前库存数量和最后一次事件 IDaccount_balance按客户和资源维度存当前余额order_fulfillment按订单维度存已发货数量、待履约数量。写入事件后在同一个事务里更新对应投影表或者在事务提交后发消息异步更新投影。关键是投影表可以被丢弃和重建因为它只是事件表的缓存事件表才是唯一真相。如果某天发现投影数据不对直接从事件表重放几分钟就能恢复。这种从事件重算的安全性传统改余额模型是给不了的。5.3 从最容易出事的模块开始迁移如果是一个已经跑了两年的老系统别指望一次性把所有表都改成 REA。我的经验是从最容易出问题的模块切入通常有三个候选库存台账、客户余额或钱包、积分和优惠券核销。它们的共同点是金额或数量敏感状态变化多事后对账频繁。迁移步骤可以这样设计把现在的库存、余额作为初始快照事件写入事件表记录快照时点后续所有新增的入库、出库、支付、退款操作全部写入事件表投影表承担原有业务查询老系统的状态字段不再作为主数据新旧系统并行跑一段时间每天对账确认数据一致后再把后台管理页面切换到新逻辑。这里要特别说明初始快照事件不是篡改历史它是截至某时点为止的累计事实。快照之后的流水全部追加任意时刻的余额都可以用快照 后续流水重算出。这个技巧能让老系统平稳过渡不用推倒重来。5.4 我现在的选型边界和一些体会做了几个项目之后我反而不建议所有系统都无脑上 REA。如果只是内部一个几十人用的管理后台直接改状态字段最省事引入事件建模的成本反而会拖慢进度。我的判断标准是三个问题这个数据如果错了需不需要知道是谁在什么时间做了什么这个状态是不是由多个业务动作同时决定历史数据有没有可能被随时按新口径重新计算只要有一个答案是是REA 就值得用。我自己在真正落地时还有一条底线事件只增不改投影随时可拆。团队里必须有人能把状态是投影这件事讲清楚否则过两个月就会有人忍不住去 update 事件表。把这些想明白REA 就不只是又一个建模理论而是能实实在在帮你睡个好觉的对账工具。
看到REA这三个字母懂行的人会先想到资源、事件、主体Resource-Event-Agent而不是某个框架或库名。这套模型最早是给会计信息系统做业务建模用的但我发现它解决的不只是记账问题电商、供应链、积分、钱包这些系统里最烦人的状态不同步本质上都是因为把当前状态当成了事实。这篇我结合在一个订单和库存反复对不上的项目里踩过的坑把 REA 的建模思路和落地表结构一次讲清楚适合正在做订单、库存、账务、积分这类业务的后端开发、架构师和数据产品经理。如果你只是想找一个能直接抄作业的表结构可以直接跳到第3章如果你想弄明白为什么改状态字段这种最顺手的设计会在半年后变成事故源头建议从第1章往下读。我的结论先放在这状态不是数据状态是事件的投影。这句话理解了整个 REA 模型就通了。1. 为什么当前状态式建表会让业务系统越改越乱1.1 我栽过的跟头状态字段引发的连锁事故之前做过一个零售订单系统早期设计非常正常订单表里放一个status字段从待支付到已支付、已发货、已完成库存表直接存当前剩余数量用户钱包表直接存当前余额。所有业务逻辑都围绕判断当前状态 修改当前状态展开。刚开始数据量小一切岁月静好。等促销、退款、分批发货、客服人工改单开始出现问题就来了。第一个事故发生在退款流程用户申请退款代码把订单状态改成了已退款也把钱包余额加回去了但库存表没有回补。为什么因为退款逻辑关注的只是订单状态它压根不知道这个订单对应哪几个库存流水。第二个事故是运营手工把订单状态改成已完成实际上仓库根本没发货数据凭空丢失了事实依据。这些问题的根源不是某一段代码写错了而是整个建模方式有问题status字段是当前值不是一个业务事实。改当前值不留任何可审计的痕迹一旦多个功能模块都要改动这个值状态机就会以指数级膨胀。今天加一个部分发货明天加一个售后中后天再加一个风控冻结每个状态都得考虑前一状态、后一状态、谁可以改、改完要不要触发回调。系统不爆炸才怪。1.2 REA 的第一性原理状态是事件的投影REA 模型给出的回答很简单不要存现在是什么状态只存历史上发生了什么事件。三个字母分别是Resource资源有价值、可计量、可被组织控制的东西比如现金、库存商品、应收账款。Event事件导致资源增加或减少的经济动作比如收款、发货、入库、退货。Agent主体参与事件的人、部门或组织比如客户、仓库操作员、供应商。它们之间的关系也很好理解一个主体在某个时间点发起或参与了某个事件这个事件改变了某种资源的数量。所有当前状态比如库存剩多少、客户还欠多少钱、订单走到哪一步都不是独立存储的事实而是把事件按时间汇总之后算出来的结果。这跟银行账户是一个道理流水表才是事实余额表只是把流水加总后的投影。银行不会因为余额显示异常就去改流水而是重新计算余额。REA 就是把这种思维方式从金融领域搬到了更宽泛的业务系统建模里。在这个模型里订单状态不是字段而是有没有支付事件、有没有发货事件、有没有退货事件的逻辑组合。库存也不是字段而是入库事件数量减出库事件数量的聚合结果。谁想问为什么都能顺着事件追溯回去。2. REA 三类核心对象拆解资源、事件、主体怎么选2.1 资源有价值、可计量、可控制三者缺一不可很多人在建资源表时会把资源等同于商品或钱然后就开始纠结优惠券算不算、服务算不算、客户信任算不算。我的判断标准只有三个缺一个都不建模成资源有价值直接或间接带来经济利益。现金有价值库存商品有价值应收账款有价值积分有价值可计量可以用数量或金额量化。计量单位不一定是件还可以是小时、次数、公里、克可控制企业或系统对其有支配权或管理权。客户满意度虽然重要但你既不能准确计量也不能单方面控制它所以不适合做资源。服务类业务也适用。比如一个咨询项目计量单位是小时一次云服务调用计量单位是次。只要你能定义单位就能把它放进资源表。实战中我会给资源表加上类型字段create table resource ( id bigint primary key, name varchar(100) not null, unit varchar(20) not null, -- 件、小时、元、次 resource_type varchar(30) not null, -- inventory / cash / receivable / point is_monetary boolean not null default false );货币性资源和非货币性资源的处理方式不太一样。现金、应收账款这类金额资源事件里记录的是金额库存、积分这类资源事件里记录的是数量可能还需要换算金额。这样拆开后续做总账和业务台账时会清爽很多。2.2 事件真正能改写资源账目的原子动作事件是整个 REA 模型里最重要也最容易搞错的对象。很多人会把业务操作直接当成事件比如用户登录客服改备注这些操作不改变任何资源的经济价值不该进事件表。我判断一个动作能不能成为经济事件只看四点是否发生在某个时间点而不是持续模糊的时间段是否明确地增加或减少了某种资源是否有可计量的数量或金额是否至少涉及一个主体。比如下单本身不是经济事件因为商品还没有转移、钱还没付它只是产生了一个承诺支付发货退货入库才是经济事件。如果按这个标准绝大多数状态字段问题都会暴露出来你根本没有支付事件凭什么把订单改成已支付事件之间还存在配对关系。一个典型的交易我的资源减少必然伴随着另一个资源的增加REA 里叫事件对偶duality。比如发货库存商品减少同时应收账款增加收款应收账款减少现金增加。后面第3章的案例会具体演示这种配对。2.3 主体谁有权操作比是谁更重要主体可能是我实际项目里最容易被忽略的一块。很多系统的操作记录只有user_id但user_id代表的是登录账号它无法回答两个关键问题这个人当时代表哪个组织他有没有权限做这个操作采购场景特别明显下单人是一个采购专员付款方是公司收货地址是某个门店仓库。如果事件表里只记录了下单人的user_id后面的对账、审计、责任追溯全都会卡住。所以在事件表里我至少会区分两个主体字段操作主体谁发起的动作和对手主体和谁发生的交易。对于内部授权关系可以单独建模也可以简化成一张主体关系表。原则是事件记录必须回答是谁、代表谁、对谁三个问题否则它就不是一个完整的事实。3. 用一个商城订单案例把 REA 完整落成表结构3.1 从下单到收款一条订单拆成哪几个经济事件用一个最常见的场景某客户在线买一件衣服价格 100 元优惠券抵扣 10 元实际支付 90 元仓库发货客户收货。按 REA 的拆法这条订单不是一条记录而是几个独立事件支付事件客户的钱包或银行账户减少 90 元平台钱包或待清算资金增加 90 元发货事件库存商品减少 1 件同时产生一笔应收账款如果发货时还没收款或确认资金入账如果已经收款后续收款核销事件如果发货时挂的是应收账款收到钱后再把应收账款清零、现金增加。这里有一个关键认知收入不是资源也不是事件。收入是发货事件和收款事件共同作用的统计结果。你不要在系统里专门插入一个收入增加事件那样会造成事实重复对账时极易出现两边数字对不上。REA 的做法是只记录资源变化收入报表通过事件聚合算出来。下单这个动作我通常会留在承诺层也就是继续保留订单头、订单行但订单行只表示承诺要交付的商品。实际库存变化必须来自发货事件。这样承诺量和实际量就分开了后面做部分履约会非常自然。3.2 表结构怎么设计一张事件表撑起库存和应收最小可用的落地方案就是一张扁平的经济事件表。每个事件记录一笔资源增减可以满足的库存、余额、应收账款查询。create table economic_event ( id bigint primary key, event_type varchar(50) not null, -- payment / shipment / return / adjustment occurred_at timestamptz not null, resource_id bigint not null, direction varchar(10) not null, -- in / out quantity numeric(18,4) not null, unit_price numeric(18,4) not null, base_amount numeric(18,4) not null, original_amount numeric(18,4) not null, currency varchar(10) not null, rate_to_base numeric(18,6) not null, agent_id bigint not null, -- 操作主体 counterparty_id bigint not null, -- 对手主体 ref_document varchar(64) not null, -- 关联订单号/支付流水号 ref_event_id bigint null, -- 关联事件如退货指向原发货 created_at timestamptz not null default now() ); create index idx_event_resource_time on economic_event(resource_id, occurred_at); create unique index uq_event_ref on economic_event(ref_document);这个表能解决大部分问题但它有一个明显不足一个支付事件既影响应收账款又影响现金如果只建一行就得把两个资源塞进一条记录语义会很拧巴。所以我在实际项目中更推荐事件头 事件分录的结构类似记账凭证和分录的关系create table economic_event ( id bigint primary key, event_type varchar(50) not null, occurred_at timestamptz not null, agent_id bigint not null, counterparty_id bigint not null, ref_document varchar(64) not null ); create table event_entry ( id bigint primary key, event_id bigint not null references economic_event(id), resource_id bigint not null, direction varchar(10) not null, quantity numeric(18,4) not null, unit_price numeric(18,4) not null, base_amount numeric(18,4) not null, currency varchar(10) not null, rate_to_base numeric(18,6) not null );一个支付事件下挂两条分录应收账款减少 90现金增加 90。一个发货事件下挂两条分录库存减少 1 件应收账款增加 90。每次对账都可以从事件重新推导永远不会出现钱包余额加了但库存没回补的情况因为所有改动都发生在同一套事件机制里。3.3 余额和库存怎么算一条 SQL 复现账目有了事件表当前库存就是所有库存资源的流入减流出select resource_id, sum(case when direction in then quantity else -quantity end) as current_balance from event_entry where occurred_at now() group by resource_id;某个客户当前还欠多少钱也就是应收账款余额可以这样算select counterparty_id, sum(case when direction in then base_amount else -base_amount end) as receivable_balance from event_entry where resource_id 1001 -- 应收账款资源ID group by counterparty_id;这两条 SQL 看起来很简单但它的意义是任何时刻的余额都可以用同一套事件重算出来。审计时不需要相信某个当前值字段只需要把事件重新加一遍。这也让我在排查问题时节省了大量时间——某个数字不对不再去猜哪张表被谁改过直接按事件筛选很快就能定位到是哪条流水写错了。3.4 价格、折扣、税费这种附加属性放哪里这是我在项目里被问得最多的问题订单有商品原价 100优惠券抵扣 10税费 5实付 90这些字段该塞哪如果用的是扁平事件表最省事的办法是把单价记成 90把原价和优惠折扣放在订单表里供展示。但这样一做审计链就断了一半你无法从事件表看出这 90 元是由 100 元商品、-10 元折扣、0 元税组成的后续如果要对折扣单独分析就得去 join 订单表。更干净的做法是把折扣和税费也建模成资源分录。一个发货事件可以有三条分录库存商品 out数量 1金额 100折扣资源 in负向调整金额 -10税费资源 in金额 5。这样收入报表、折扣费用报表、税费报表都可以直接看事件分录不用再从 UI 层硬挖数据。缺点是表行数会增加事件写入会变复杂。如果业务对折扣和税费没有独立审计要求也可以妥协事件分录只记最终成交金额订单行保留原始明细。取舍的标准只有一个——将来会不会有人拿着这个数据去问为什么是这个数如果会就别省。4. 边界场景怎么保持模型干净退货、部分履约、多币种4.1 退货不是负数流水而是独立反向事件我第一次用 REA 建模退货时也想走捷径既然发货是库存 out 1退货就记库存 in -1等于把原事件冲平。后来发现这是一个典型的坑。如果退货以负数数量的形式并入原发货事件你的领导或审计会看到一条数量为负的出库记录它到底是系统异常、数据错误还是真的退货完全不可判定。而且退货本身还有验收、质检、是否重新入库、退款金额是多少这些独立信息把它们揉在一个旧事件里等于把所有后续业务都锁死在历史数据上。正确姿势是创建一个新的退货事件它有自己的事件 ID、时间、操作主体ref_event_id指向原发货事件。分录如下库存商品 in数量 1应收账款或现金 out/调整金额 90。原发货事件完全不动。查询原发货量仍然是 1查询退货量也能单独统计出来。这种追加不修改的模式才符合事件不可变原则也方便日后做售后分析、退款结算和库存效期管理。4.2 部分履约和分批发货让状态自然推导订单买了 3 件商品仓库先发了 2 件剩 1 件等补货后再发。传统状态机方案里你得新增一个部分发货状态然后开始处理部分发货到已发货之间的各种组合。REA 方案完全没有这个状态。订单行记录的是承诺数量 3发货事件记录的是实际出库 2过几天再补一条发货事件出库 1。任何时候想知道这个订单发完了没有只需要比较承诺数量和发货事件的汇总数量select ol.order_id, sum(ol.quantity) as ordered_qty, coalesce(sum(case when ee.direction out then ee.quantity else 0 end), 0) as shipped_qty from order_line ol left join event_entry ee on ee.ref_document ol.order_line_doc where ol.order_id 12345 group by ol.order_id;这里的关键是订单履行状态不是一个字段而是承诺量减实际量的计算结果。发货不足就继续待履约全部发完自然就是已完成。需要往状态机里加的状态在这里全都消失了。这个设计对供应链里的分批到货、部分缺货、多次售后特别实用。4.3 多币种与汇率把汇率锁进事件时间点做跨境业务时最容易出现的问题是金额漂移。假设订单发生时美元兑人民币汇率是 7.1事件分录里记了 $100 对应 ¥710一个月后汇率变成 7.3如果资产余额表里的值被定期重估那你翻历史报表时会发现上个月的收入数字跟着当前汇率变了这显然不可接受。REA 的解决思路是汇率是事件发生时刻的事实不是余额表的属性。每条分录必须同时记录原始币种金额、原始币种、汇率和折算后的基准币种金额。基准币种金额在事件写入时锁定不做自动重算。期末如果需要按最新汇率重估货币性资产可以作为一个独立的重估事件写入分录方向是汇兑损益调整。这样既保持了历史事件原貌又满足了财务上按期末汇率披露的需求。两点必须同时存在缺一个都会在未来某天对不上账。4.4 幂等与并发防止账目重复入账事件表是追加式的但这不代表不会重复。支付渠道回调重试、用户重复点击提交、消息队列重复消费都可能让同一个业务动作产生两条事件分录。所以我对事件表有一个硬性要求业务原始凭证号必须唯一。在上面的表结构里ref_document字段承载的就是这个幂等键。支付回调时用支付渠道返回的流水号作为ref_document并建唯一索引。如果来了重复回调数据库会直接拒绝第二次插入事件就不会写重。并发方面两个仓库操作员同时出库同一资源时事件表本身很难做简单的行锁约束。我的做法是写入事件前先对资源 ID 做一次聚合校验比如库存是否够用在强一致性要求高的场景可以给资源记录加乐观锁版本号事件写入时校验版本号。普通业务量下这种程度的保护已经够用了。5. 渐进落地策略不推翻系统也能用上 REA5.1 事件溯源是存储机制REA 是业务语义很多人会把 REA 和事件溯源Event Sourcing混为一谈。它们其实是两层的概念事件溯源说的是怎么存REA 说的是怎么对业务建模。事件溯源要求系统只追加事件日志不直接修改当前状态REA 告诉这些事件应该长什么样必须包含资源、方向、数量、金额、主体、对手主体、时间并且状态全部可以投影计算。你可以只做事件溯源而不遵循 REA那样事件虽然不可变但每个团队可能各写各的事件类型五花八门最后还得靠人脑去对语义。也可以只用 REA 的概念设计关系表不用事件溯源那一整套基础设施。我倾向于两者结合存储层用只追加的事件表业务语义层用 REA 的三类对象来约束事件结构。这样既保证了可追溯又避免了什么都能塞事件带来的混乱。5.2 查询走投影为库存和账单准备读模型有人会质疑如果所有查询都实时聚合事件表量一大肯定扛不住。这个担心有道理但解决方案不是回到存状态字段而是建投影表也就是读模型。投影表就是一个缓存起来的统计数据。比如inventory_snapshot按资源维度存当前库存数量和最后一次事件 IDaccount_balance按客户和资源维度存当前余额order_fulfillment按订单维度存已发货数量、待履约数量。写入事件后在同一个事务里更新对应投影表或者在事务提交后发消息异步更新投影。关键是投影表可以被丢弃和重建因为它只是事件表的缓存事件表才是唯一真相。如果某天发现投影数据不对直接从事件表重放几分钟就能恢复。这种从事件重算的安全性传统改余额模型是给不了的。5.3 从最容易出事的模块开始迁移如果是一个已经跑了两年的老系统别指望一次性把所有表都改成 REA。我的经验是从最容易出问题的模块切入通常有三个候选库存台账、客户余额或钱包、积分和优惠券核销。它们的共同点是金额或数量敏感状态变化多事后对账频繁。迁移步骤可以这样设计把现在的库存、余额作为初始快照事件写入事件表记录快照时点后续所有新增的入库、出库、支付、退款操作全部写入事件表投影表承担原有业务查询老系统的状态字段不再作为主数据新旧系统并行跑一段时间每天对账确认数据一致后再把后台管理页面切换到新逻辑。这里要特别说明初始快照事件不是篡改历史它是截至某时点为止的累计事实。快照之后的流水全部追加任意时刻的余额都可以用快照 后续流水重算出。这个技巧能让老系统平稳过渡不用推倒重来。5.4 我现在的选型边界和一些体会做了几个项目之后我反而不建议所有系统都无脑上 REA。如果只是内部一个几十人用的管理后台直接改状态字段最省事引入事件建模的成本反而会拖慢进度。我的判断标准是三个问题这个数据如果错了需不需要知道是谁在什么时间做了什么这个状态是不是由多个业务动作同时决定历史数据有没有可能被随时按新口径重新计算只要有一个答案是是REA 就值得用。我自己在真正落地时还有一条底线事件只增不改投影随时可拆。团队里必须有人能把状态是投影这件事讲清楚否则过两个月就会有人忍不住去 update 事件表。把这些想明白REA 就不只是又一个建模理论而是能实实在在帮你睡个好觉的对账工具。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
