如果你做过一段时间后端开发或系统架构大概率遇到过这种尴尬业务方开口说“我们只要一个简单的进销存”结果需求文档越写越长从库存到订单再到对账最后变成一个半个ERP。传统的关系建模——以账号、凭证、流水为中心——一旦业务规则变化改表结构能改到怀疑人生。后来我接触到一个叫REA的建模框架思路一下子被打开了。REA 的全称是Resource-Event-Agent即“资源-事件-代理”最早是会计信息系统领域提出的一种替代性建模思路但后来大家发现它能用来描述几乎所有的交易型业务过程。核心思想特别朴素业务就是“代理们通过事件交换资源”。对于做领域建模、系统设计、数据架构的同学来说这是一个很值得放进工具箱的思维模型。今天我就把这套东西掰开揉碎讲一遍并给一个可以直接照抄的建模案例。1. REA 到底在说什么从记账凭证到经济实质1.1 传统借贷记账法为什么不够用我们熟悉的复式记账法核心是“有借必有贷借贷必相等”。它用借贷科目描述资金和其他账户的增减确实能保证会计恒等但它有一个问题数据模型是以“凭证-分录-科目”为中心的。也就是说系统里最核心的实体是那张记账凭证而真实的业务对象比如客户、订单、发货、付款全部被抹平成了一串借贷数字。这样做在财务核算上没问题可一旦要做业务系统麻烦就来了。你查一张销售单要先从凭证抬头查到分录再关联到辅助核算项再反推是哪个客户哪个商品。业务人员看到的尽是“借应收账款贷主营业务收入”不是“客户A在下午三点买了三杯拿铁”。而且科目体系是人为规定的不同企业对同一个业务给的科目可能完全不一样数据模型自然难以复用。传统的扩展办法是不断加辅助核算、加自定义字段最终系统变成了一个大杂烩。真正的问题在于我们选错了建模出发点。凭证是会计人员为了核算而发明的“输出格式”不应该成为业务真相的来源。1.2 REA 的由来与核心主张上世纪八十年代有研究者提出一个大胆的问题如果不从“记账”出发而是从“经济活动的本质”出发会计系统会长什么样结论就是 REA 模型的雏形。它主张任何一个公司或组织本质上是参与了一系列经济事件的集合而信息系统应该描述这些事件的实质不是描述记账格式。REA 的基本构件只有三个Resource资源具有经济价值、可以被获取或消耗的对象比如现金、商品、原材料、设备、积分、服务工时。Event事件在特定时间点发生的经济活动比如销售、采购、收款、付款、退货。事件是时序的、不可变的它是系统的“事实来源”。Agent代理参与事件的个体或组织包括内部员工和外部客户、供应商、分销商。把所有业务还原成这三个构件你会发现订单和凭证都只是“输入或输出的某种呈现”而不是底层核心。给一个生活类比的例子你去超市购物你是代理收银员是另一个代理你把商品拿到手商品是资源“扫码付款”和“收银台交付”是一组事件。整个交易如果用借贷记账法写会很绕但用 REA 表达每一环都清清楚楚。1.3 REA 与领域驱动设计的天然契合如果你在做 DDD领域驱动设计REA 会让你觉得“似曾相识”。DDD 里的实体、值对象、聚合在 REA 中都能找到对应Agent 通常是天然的聚合根Event 是事实记录很接近事件溯源里的领域事件Resource 则承担实体和值对象的职责。我自己的体会是REA 特别适合作为事件溯源建模时的“概念模板”。你不需要从零开始定义什么是领域事件只需要问自己哪一步改变了资源的状态哪一步涉及哪些代理把这些回答沉淀成事件类型代码里的聚合设计会非常稳。但这绝不意味着 REA 是银弹。它对高度复杂的合同条款、柔性审批流程支持有限更适合业务边界清晰、以资源流转为中心的交易型系统。写代码之前先看清楚边界比强行套模型重要得多。2. 拆开 REA三个构件和三种核心关系2.1 资源、事件、代理各管哪一摊先说说三个构件的划分标准这是建模时最容易含糊的地方。Resource必须是“有经济价值且可计量”的对象。现金、商品、原料、积分都是典型资源。但有个常见的坑订单既不是资源也不是事件。订单本身不产生经济价值它只是交易意图的记录在严格 REA 里属于“承诺”层。类似的还有购物车、草稿单、合同台账。把承诺层和事件层混在一起是早期建模容易翻车的原因。Event是改变资源状态的活动。注意三个关键词时间点、不可变、事实。一次销售、一次退款、一次原料报废发生后就不该再修改只能通过追加反向事件来纠正。系统的“可信度”就来自这里。Agent的范围比“用户”更宽。客户、供应商、内部的销售和仓管甚至一个自动化机器人只要参与了经济事件都能建模为 Agent。不同 Agent 只是角色属性不同底层表可以复用同一张代理表。2.2 事件之间的对偶关系REA 里最容易被忽略、又最重要的一块是事件之间的Duality对偶关系。一个资源流出的事件必然存在一个资源流入的事件与之对应。比如“销售发货”是商品从我们这里流出那么就应该有一个“收到货款”或“确认应收”的事件让现金/债权流入。两个事件互相配对构成经济上的完整循环。对偶关系在做对账时特别有用。系统只要维护好事件对偶就能自动生成应收、应付、库存变化。传统方式里这些是分散在不同模块的经常出现仓库发货了但财务没确认、客户付款了但订单没关闭的情况。用 REA 建模后这类问题会在模型层就被约束住。2.3 从存量到流量的视角切换传统业务表习惯存余额、存库存这类“存量字段”比如一个products表直接放stock_qty一个accounts表直接放balance。看起来方便实际上隐患极大一旦出现并发修改、漏更新、历史追溯时数据对不上账根本不知道是哪个环节出的错。REA 给出的是另一个视角Events 记录的是流量存量是聚合出来的。也就是说任何时点的库存 期初数量 所有入库事件 - 所有出库事件余额同理。这个思想其实和银行账户流水一模一样——余额不是单独存储的字段而是交易流累积的结果。这在实现时能大幅减少脏数据。你要做的要么是查询时实时聚合要么定期从事件流跑一次数生成快照。前者适合数据量可控的场景后者适合高频交易场景。但无论哪种底层的可信事实源都是事件流而不是一坨可以被随意 UPDATE 的状态字段。2.4 多资源的流入流出实际业务中一个事件往往涉及多个资源。比如“加工生产”这个事件原料 A 和原料 B 同时流出产成品 C 流入。这种情况在 REA 中并不冲突因为资源是一个类别的概念具体关系可以通过“事件-资源关联表”来表达每条关联带数量、单价、批号等属性。我见过有人把多资源事件硬拆成多个单资源事件导致半小时的操作在系统里变成十几条碎片记录追溯困难。正确的做法是保留一个复合事件头和明细行事件头和代理关联明细行和资源关联。这样既符合 REA 的思想又不会丢失业务完整性。3. 手把手实战用 REA 做一套咖啡店点单收款模型这一章我拿“咖啡店点单收款”来完整走一遍建模流程。选这个场景是因为它小、贴近生活、又足够展示 REA 的大部分特性。你可以直接把它替换成零售、外卖、会员充值等任何资源型业务。3.1 先圈定业务边界我们要实现的咖啡馆业务能力顾客到店点单咖啡师制作店员交付收银员收款如果顾客不满意可能退款咖啡豆、牛奶等原料需要消耗库存收银台现金/电子余额发生变化。目标建立一套可追溯的订单、库存和资金数据模型支持财务对账、库存盘点和经营分析。注意这里我们没有做复杂的会员积分和复杂的促销组合让例子保持在可理解的范围。3.2 识别资源、事件、代理按 REA 的步骤先把业务过程里出现的元素归类。资源Resource资源说明咖啡豆原材料制作咖啡时消耗牛奶原材料制作咖啡时消耗杯装成品交付给顾客的商品现金收银台收到的现金电子账户余额扫码支付形成的结余事件Event事件说明制作咖啡师消耗原料产出成品交付成品从门店流向顾客收款顾客支付现金或扫码资金流入门店退款资金反向流出需要冲抵前面对偶事件代理Agent代理说明顾客外部代理购买方收银员内部代理负责收款咖啡师内部代理负责制作这里有个核心判断“点单”不算经济事件。顾客说“我要一杯拿铁”此时没有任何资源发生状态变化也没有资金流动。它只是创造了一个购买意图属于承诺层的记录。你可以单独建一张orders表存承诺后续事件通过秩序号关联但不要把“下单”和“制作”“收款”混在同一张事件表里。3.3 画出关系图转成关系表严格 REA 有三组内在关系落到设计上就是外键和关联表。Event 与 Resource制作事件关联原料资源和产出资源交付事件关联成品资源收款事件关联现金/账户资源。Event 与 Agent每个事件至少涉及内部代理和外部代理。Event 与 Event收款与交付构成对偶。下面是一组可用的表结构用字段简化表达-- 代理表 CREATE TABLE agents ( id BIGINT PRIMARY KEY, agent_type VARCHAR(32), -- CUSTOMER / EMPLOYEE / SUPPLIER name VARCHAR(128) ); -- 资源表 CREATE TABLE resources ( id BIGINT PRIMARY KEY, resource_type VARCHAR(32), -- RAW_MATERIAL / PRODUCT / CASH / ACCOUNT name VARCHAR(128) ); -- 经济事件明细 CREATE TABLE economic_events ( id BIGINT PRIMARY KEY, event_type VARCHAR(32), -- PRODUCE / DELIVER / RECEIVE / REFUND happened_at TIMESTAMP, resource_id BIGINT REFERENCES resources(id), agent_id BIGINT REFERENCES agents(id), quantity NUMERIC(18, 3), unit_amount NUMERIC(18, 2), opposite_event_id BIGINT REFERENCES economic_events(id) -- 对偶事件 ); -- 承诺层订单表事件的事实由 economic_events 保证 CREATE TABLE orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(32), customer_id BIGINT REFERENCES agents(id), created_at TIMESTAMP );几个设计要点economic_events只有追加没有 UPDATE 业务字段的操作。出错了就新增一条反向冲销事件。opposite_event_id用来维护对偶关系可以让收银和交付绑定退款和原收款绑定。不要在resources表里设计current_stock字段。库存量通过SUM(quantity)按资源分组聚合出来。提示如果交易量特别大实时聚合会拖慢查询可以加一张按天/按小时聚合的快照表。快照本身就是一种“物化视图”由事件流生成依然不破坏底层事实源。3.4 一次完整销售的“事件时间线”假设顾客下单后流程如下顾客提交需求系统在orders表落一条承诺记录。此时没有任何资金和库存变化。咖啡师制作咖啡写入一条PRODUCE事件消耗咖啡豆和牛奶产出杯装成品。注意这里一个事件同时关联多种资源需要单独的资源变更明细表或者把economic_events与economic_events_detail拆成主从表。店员把咖啡递给顾客写入一条DELIVER事件成品资源流出。收银员收款写入一条RECEIVE事件现金/账户资金流入并设置opposite_event_id指向DELIVER事件完成对偶配对。如果顾客要求退款写入一条REFUND事件资金流出对偶指向RECEIVE事件。这段时间线走完后系统天然能回答当前库存剩多少——按时间过滤所有PRODUCE和DELIVER的量求和即可。今天收了多少现金——所有RECEIVE事件的资金量汇总。哪些交付还没收款——找DELIVER事件按opposite_event_id查为空的那一批。这些在传统表结构里往往要写好几段复杂 SQL在 REA 模型下是简单直白的聚合查询。4. 落地 REA 时最容易踩的坑4.1 把所有表都做成大流水账有人学完 REA 很兴奋把任何操作都往事件表里塞包括用户登录、页面点击、字段修改。结果事件表变成了垃圾堆业务事件和系统日志混在一起既不好查也不安全。我的建议是区分经济事件和系统事件。只有改变资源状态或代理之间经济关系的才算经济事件放进economic_events其余统统落独立的操作日志表。事件表越纯粹聚合查询越高效。4.2 忽略对偶完整性只记销售不记收款或者只记发货不记收货是常见建模疏漏。一旦对偶断了财务对账马上露馅。落地时我习惯用事务把成对事件一起写入或者在状态机里限制交付事件必须存在待配对的收款事件退款事件必须关联已有的收款事件。早期阶段宁可先写死校验规则也不要放任业务人员手工拆单。否则上线三个月后会迎来一场数据清洗噩梦。4.3 把“资源余额”设计成直接更新的字段这是我最想强调的坑。曾经有个模块为了查询方便直接在resources表里加了一个balance字段每次事件发生时先写事件又写余额。后来某个报表需要一个历史时点数据发现余额根本回溯不了。更糟的是有一次定时任务跑了两次余额被叠加上去全盘对账失败。正确做法是事件只追加余额通过事件聚合计算。不得不做缓存时也一定要保证余额可重建、可校验并且定期跟事件流对账。宁可牺牲一点查询性能也要保住数据可信。4.4 非要所有业务都套进 REAREA 适合交易型、资源型业务。如果是内容管理 CMS、社交信息流、文档协作这类系统核心对象是内容和人并不存在明确的资源经济流转硬套 REA 只会让模型扭曲变形。判断依据很简单业务方聊需求时会频繁提到“入库、出库、收款、扣款、余额”这些词就值得用 REA如果提到的是“发布、编辑、评论、权限”那请直接用领域模型别给自己找不痛快。4.5 忽略“时间”的多重身份事件一定涉及发生时间、业务时间、记录时间。比如顾客在晚上 23:59 提交的退款第二天凌晨系统才入库又比如财务希望按“归属期”而不是“操作时间”统计。如果事件表只放一个created_at这类需求来了全傻眼。建议字段拆成至少三个event_time业务发生时间、recorded_at系统入库时间、period财务归属期可按规则自动生成。后期做报表、做审计都能少掉很多争议。4.6 常见问题速查现象排查方向处理建议库存对不上账看是否有直接 UPDATE 库存表的代码改造为事件追加重跑聚合退款后交易额异常检查退款事件的对偶关系是否指向原收款补全opposite_event_id历史报表数据不同看是否用快照表覆盖而非事件源计算增加事件流校验任务定期对账“下单”也进了事件表检查事件分类逻辑拆分承诺层和事件层并发退款导致余额为负事件写入缺少幂等和预校验加唯一约束和预检查4.7 我个人在实操中的几点体会我实际做过一个订单、支付、退款、库存统一到 REA 事件流底座的项目最深的体会是收益不在技术上的“酷炫”而是业务方终于能用一套逻辑向老板解释“钱货两清”或者“还差几张发票”。这种跨模块的语义统一在传统表结构里很难做到。另外团队里新人对 REA 很容易产生两种极端要么觉得太抽象不会用要么觉得万能天天套。建议引入初期先安排一个小业务范围试点把销售和收款做成完整例子再慢慢扩展比一上来就重建核心系统稳妥得多。还有一个值得尝试的扩展方向把事件流同时输出给数据分析团队让他们基于同样的 REA 数据源做经营分析和预测而不是让他们去读一堆科目和分录整理出的二手表。这样整个公司的“业务语言”会逐渐统一沟通成本肉眼可见地下降。
如果你做过一段时间后端开发或系统架构大概率遇到过这种尴尬业务方开口说“我们只要一个简单的进销存”结果需求文档越写越长从库存到订单再到对账最后变成一个半个ERP。传统的关系建模——以账号、凭证、流水为中心——一旦业务规则变化改表结构能改到怀疑人生。后来我接触到一个叫REA的建模框架思路一下子被打开了。REA 的全称是Resource-Event-Agent即“资源-事件-代理”最早是会计信息系统领域提出的一种替代性建模思路但后来大家发现它能用来描述几乎所有的交易型业务过程。核心思想特别朴素业务就是“代理们通过事件交换资源”。对于做领域建模、系统设计、数据架构的同学来说这是一个很值得放进工具箱的思维模型。今天我就把这套东西掰开揉碎讲一遍并给一个可以直接照抄的建模案例。1. REA 到底在说什么从记账凭证到经济实质1.1 传统借贷记账法为什么不够用我们熟悉的复式记账法核心是“有借必有贷借贷必相等”。它用借贷科目描述资金和其他账户的增减确实能保证会计恒等但它有一个问题数据模型是以“凭证-分录-科目”为中心的。也就是说系统里最核心的实体是那张记账凭证而真实的业务对象比如客户、订单、发货、付款全部被抹平成了一串借贷数字。这样做在财务核算上没问题可一旦要做业务系统麻烦就来了。你查一张销售单要先从凭证抬头查到分录再关联到辅助核算项再反推是哪个客户哪个商品。业务人员看到的尽是“借应收账款贷主营业务收入”不是“客户A在下午三点买了三杯拿铁”。而且科目体系是人为规定的不同企业对同一个业务给的科目可能完全不一样数据模型自然难以复用。传统的扩展办法是不断加辅助核算、加自定义字段最终系统变成了一个大杂烩。真正的问题在于我们选错了建模出发点。凭证是会计人员为了核算而发明的“输出格式”不应该成为业务真相的来源。1.2 REA 的由来与核心主张上世纪八十年代有研究者提出一个大胆的问题如果不从“记账”出发而是从“经济活动的本质”出发会计系统会长什么样结论就是 REA 模型的雏形。它主张任何一个公司或组织本质上是参与了一系列经济事件的集合而信息系统应该描述这些事件的实质不是描述记账格式。REA 的基本构件只有三个Resource资源具有经济价值、可以被获取或消耗的对象比如现金、商品、原材料、设备、积分、服务工时。Event事件在特定时间点发生的经济活动比如销售、采购、收款、付款、退货。事件是时序的、不可变的它是系统的“事实来源”。Agent代理参与事件的个体或组织包括内部员工和外部客户、供应商、分销商。把所有业务还原成这三个构件你会发现订单和凭证都只是“输入或输出的某种呈现”而不是底层核心。给一个生活类比的例子你去超市购物你是代理收银员是另一个代理你把商品拿到手商品是资源“扫码付款”和“收银台交付”是一组事件。整个交易如果用借贷记账法写会很绕但用 REA 表达每一环都清清楚楚。1.3 REA 与领域驱动设计的天然契合如果你在做 DDD领域驱动设计REA 会让你觉得“似曾相识”。DDD 里的实体、值对象、聚合在 REA 中都能找到对应Agent 通常是天然的聚合根Event 是事实记录很接近事件溯源里的领域事件Resource 则承担实体和值对象的职责。我自己的体会是REA 特别适合作为事件溯源建模时的“概念模板”。你不需要从零开始定义什么是领域事件只需要问自己哪一步改变了资源的状态哪一步涉及哪些代理把这些回答沉淀成事件类型代码里的聚合设计会非常稳。但这绝不意味着 REA 是银弹。它对高度复杂的合同条款、柔性审批流程支持有限更适合业务边界清晰、以资源流转为中心的交易型系统。写代码之前先看清楚边界比强行套模型重要得多。2. 拆开 REA三个构件和三种核心关系2.1 资源、事件、代理各管哪一摊先说说三个构件的划分标准这是建模时最容易含糊的地方。Resource必须是“有经济价值且可计量”的对象。现金、商品、原料、积分都是典型资源。但有个常见的坑订单既不是资源也不是事件。订单本身不产生经济价值它只是交易意图的记录在严格 REA 里属于“承诺”层。类似的还有购物车、草稿单、合同台账。把承诺层和事件层混在一起是早期建模容易翻车的原因。Event是改变资源状态的活动。注意三个关键词时间点、不可变、事实。一次销售、一次退款、一次原料报废发生后就不该再修改只能通过追加反向事件来纠正。系统的“可信度”就来自这里。Agent的范围比“用户”更宽。客户、供应商、内部的销售和仓管甚至一个自动化机器人只要参与了经济事件都能建模为 Agent。不同 Agent 只是角色属性不同底层表可以复用同一张代理表。2.2 事件之间的对偶关系REA 里最容易被忽略、又最重要的一块是事件之间的Duality对偶关系。一个资源流出的事件必然存在一个资源流入的事件与之对应。比如“销售发货”是商品从我们这里流出那么就应该有一个“收到货款”或“确认应收”的事件让现金/债权流入。两个事件互相配对构成经济上的完整循环。对偶关系在做对账时特别有用。系统只要维护好事件对偶就能自动生成应收、应付、库存变化。传统方式里这些是分散在不同模块的经常出现仓库发货了但财务没确认、客户付款了但订单没关闭的情况。用 REA 建模后这类问题会在模型层就被约束住。2.3 从存量到流量的视角切换传统业务表习惯存余额、存库存这类“存量字段”比如一个products表直接放stock_qty一个accounts表直接放balance。看起来方便实际上隐患极大一旦出现并发修改、漏更新、历史追溯时数据对不上账根本不知道是哪个环节出的错。REA 给出的是另一个视角Events 记录的是流量存量是聚合出来的。也就是说任何时点的库存 期初数量 所有入库事件 - 所有出库事件余额同理。这个思想其实和银行账户流水一模一样——余额不是单独存储的字段而是交易流累积的结果。这在实现时能大幅减少脏数据。你要做的要么是查询时实时聚合要么定期从事件流跑一次数生成快照。前者适合数据量可控的场景后者适合高频交易场景。但无论哪种底层的可信事实源都是事件流而不是一坨可以被随意 UPDATE 的状态字段。2.4 多资源的流入流出实际业务中一个事件往往涉及多个资源。比如“加工生产”这个事件原料 A 和原料 B 同时流出产成品 C 流入。这种情况在 REA 中并不冲突因为资源是一个类别的概念具体关系可以通过“事件-资源关联表”来表达每条关联带数量、单价、批号等属性。我见过有人把多资源事件硬拆成多个单资源事件导致半小时的操作在系统里变成十几条碎片记录追溯困难。正确的做法是保留一个复合事件头和明细行事件头和代理关联明细行和资源关联。这样既符合 REA 的思想又不会丢失业务完整性。3. 手把手实战用 REA 做一套咖啡店点单收款模型这一章我拿“咖啡店点单收款”来完整走一遍建模流程。选这个场景是因为它小、贴近生活、又足够展示 REA 的大部分特性。你可以直接把它替换成零售、外卖、会员充值等任何资源型业务。3.1 先圈定业务边界我们要实现的咖啡馆业务能力顾客到店点单咖啡师制作店员交付收银员收款如果顾客不满意可能退款咖啡豆、牛奶等原料需要消耗库存收银台现金/电子余额发生变化。目标建立一套可追溯的订单、库存和资金数据模型支持财务对账、库存盘点和经营分析。注意这里我们没有做复杂的会员积分和复杂的促销组合让例子保持在可理解的范围。3.2 识别资源、事件、代理按 REA 的步骤先把业务过程里出现的元素归类。资源Resource资源说明咖啡豆原材料制作咖啡时消耗牛奶原材料制作咖啡时消耗杯装成品交付给顾客的商品现金收银台收到的现金电子账户余额扫码支付形成的结余事件Event事件说明制作咖啡师消耗原料产出成品交付成品从门店流向顾客收款顾客支付现金或扫码资金流入门店退款资金反向流出需要冲抵前面对偶事件代理Agent代理说明顾客外部代理购买方收银员内部代理负责收款咖啡师内部代理负责制作这里有个核心判断“点单”不算经济事件。顾客说“我要一杯拿铁”此时没有任何资源发生状态变化也没有资金流动。它只是创造了一个购买意图属于承诺层的记录。你可以单独建一张orders表存承诺后续事件通过秩序号关联但不要把“下单”和“制作”“收款”混在同一张事件表里。3.3 画出关系图转成关系表严格 REA 有三组内在关系落到设计上就是外键和关联表。Event 与 Resource制作事件关联原料资源和产出资源交付事件关联成品资源收款事件关联现金/账户资源。Event 与 Agent每个事件至少涉及内部代理和外部代理。Event 与 Event收款与交付构成对偶。下面是一组可用的表结构用字段简化表达-- 代理表 CREATE TABLE agents ( id BIGINT PRIMARY KEY, agent_type VARCHAR(32), -- CUSTOMER / EMPLOYEE / SUPPLIER name VARCHAR(128) ); -- 资源表 CREATE TABLE resources ( id BIGINT PRIMARY KEY, resource_type VARCHAR(32), -- RAW_MATERIAL / PRODUCT / CASH / ACCOUNT name VARCHAR(128) ); -- 经济事件明细 CREATE TABLE economic_events ( id BIGINT PRIMARY KEY, event_type VARCHAR(32), -- PRODUCE / DELIVER / RECEIVE / REFUND happened_at TIMESTAMP, resource_id BIGINT REFERENCES resources(id), agent_id BIGINT REFERENCES agents(id), quantity NUMERIC(18, 3), unit_amount NUMERIC(18, 2), opposite_event_id BIGINT REFERENCES economic_events(id) -- 对偶事件 ); -- 承诺层订单表事件的事实由 economic_events 保证 CREATE TABLE orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(32), customer_id BIGINT REFERENCES agents(id), created_at TIMESTAMP );几个设计要点economic_events只有追加没有 UPDATE 业务字段的操作。出错了就新增一条反向冲销事件。opposite_event_id用来维护对偶关系可以让收银和交付绑定退款和原收款绑定。不要在resources表里设计current_stock字段。库存量通过SUM(quantity)按资源分组聚合出来。提示如果交易量特别大实时聚合会拖慢查询可以加一张按天/按小时聚合的快照表。快照本身就是一种“物化视图”由事件流生成依然不破坏底层事实源。3.4 一次完整销售的“事件时间线”假设顾客下单后流程如下顾客提交需求系统在orders表落一条承诺记录。此时没有任何资金和库存变化。咖啡师制作咖啡写入一条PRODUCE事件消耗咖啡豆和牛奶产出杯装成品。注意这里一个事件同时关联多种资源需要单独的资源变更明细表或者把economic_events与economic_events_detail拆成主从表。店员把咖啡递给顾客写入一条DELIVER事件成品资源流出。收银员收款写入一条RECEIVE事件现金/账户资金流入并设置opposite_event_id指向DELIVER事件完成对偶配对。如果顾客要求退款写入一条REFUND事件资金流出对偶指向RECEIVE事件。这段时间线走完后系统天然能回答当前库存剩多少——按时间过滤所有PRODUCE和DELIVER的量求和即可。今天收了多少现金——所有RECEIVE事件的资金量汇总。哪些交付还没收款——找DELIVER事件按opposite_event_id查为空的那一批。这些在传统表结构里往往要写好几段复杂 SQL在 REA 模型下是简单直白的聚合查询。4. 落地 REA 时最容易踩的坑4.1 把所有表都做成大流水账有人学完 REA 很兴奋把任何操作都往事件表里塞包括用户登录、页面点击、字段修改。结果事件表变成了垃圾堆业务事件和系统日志混在一起既不好查也不安全。我的建议是区分经济事件和系统事件。只有改变资源状态或代理之间经济关系的才算经济事件放进economic_events其余统统落独立的操作日志表。事件表越纯粹聚合查询越高效。4.2 忽略对偶完整性只记销售不记收款或者只记发货不记收货是常见建模疏漏。一旦对偶断了财务对账马上露馅。落地时我习惯用事务把成对事件一起写入或者在状态机里限制交付事件必须存在待配对的收款事件退款事件必须关联已有的收款事件。早期阶段宁可先写死校验规则也不要放任业务人员手工拆单。否则上线三个月后会迎来一场数据清洗噩梦。4.3 把“资源余额”设计成直接更新的字段这是我最想强调的坑。曾经有个模块为了查询方便直接在resources表里加了一个balance字段每次事件发生时先写事件又写余额。后来某个报表需要一个历史时点数据发现余额根本回溯不了。更糟的是有一次定时任务跑了两次余额被叠加上去全盘对账失败。正确做法是事件只追加余额通过事件聚合计算。不得不做缓存时也一定要保证余额可重建、可校验并且定期跟事件流对账。宁可牺牲一点查询性能也要保住数据可信。4.4 非要所有业务都套进 REAREA 适合交易型、资源型业务。如果是内容管理 CMS、社交信息流、文档协作这类系统核心对象是内容和人并不存在明确的资源经济流转硬套 REA 只会让模型扭曲变形。判断依据很简单业务方聊需求时会频繁提到“入库、出库、收款、扣款、余额”这些词就值得用 REA如果提到的是“发布、编辑、评论、权限”那请直接用领域模型别给自己找不痛快。4.5 忽略“时间”的多重身份事件一定涉及发生时间、业务时间、记录时间。比如顾客在晚上 23:59 提交的退款第二天凌晨系统才入库又比如财务希望按“归属期”而不是“操作时间”统计。如果事件表只放一个created_at这类需求来了全傻眼。建议字段拆成至少三个event_time业务发生时间、recorded_at系统入库时间、period财务归属期可按规则自动生成。后期做报表、做审计都能少掉很多争议。4.6 常见问题速查现象排查方向处理建议库存对不上账看是否有直接 UPDATE 库存表的代码改造为事件追加重跑聚合退款后交易额异常检查退款事件的对偶关系是否指向原收款补全opposite_event_id历史报表数据不同看是否用快照表覆盖而非事件源计算增加事件流校验任务定期对账“下单”也进了事件表检查事件分类逻辑拆分承诺层和事件层并发退款导致余额为负事件写入缺少幂等和预校验加唯一约束和预检查4.7 我个人在实操中的几点体会我实际做过一个订单、支付、退款、库存统一到 REA 事件流底座的项目最深的体会是收益不在技术上的“酷炫”而是业务方终于能用一套逻辑向老板解释“钱货两清”或者“还差几张发票”。这种跨模块的语义统一在传统表结构里很难做到。另外团队里新人对 REA 很容易产生两种极端要么觉得太抽象不会用要么觉得万能天天套。建议引入初期先安排一个小业务范围试点把销售和收款做成完整例子再慢慢扩展比一上来就重建核心系统稳妥得多。还有一个值得尝试的扩展方向把事件流同时输出给数据分析团队让他们基于同样的 REA 数据源做经营分析和预测而不是让他们去读一堆科目和分录整理出的二手表。这样整个公司的“业务语言”会逐渐统一沟通成本肉眼可见地下降。
