拿到这个标题时很多人会问“rea是什么”。它不是某个产品缩写也不是新造的网络热词而是我最近重构一个进销存系统时顺手做的小工具名。当时我已经被数据库里孤零零的订单表、发货表、收款表搞到崩溃——业务上清清楚楚的一条“卖货收钱”在库表里要靠五个表的外键拼回去业务流程一旦有变动改表比改需求还难受。后来我换了一种建模思路把自己从“先画表”拽回到“先画事件”这套方法论叫 REA全称 Resources-Events-Agents中文一般翻译成“资源-事件-代理人”。REA 并不是什么新鲜概念它最早来自会计信息系统领域距今已经有几十年。但我发现很多业务系统开发人员没听过它大家习惯了拿到需求就设计表结构、做 CRUD结果业务逻辑全散落在 service 层里数据表只是被动的存储容器。这个以“rea”为代号的项目就是想把 REA 建模方式落地成一个可以直接生成表结构、事件接口和审计日志的小框架。这篇文章不写名词解释我会把从设计思路到编码实现的过程摊开聊包括哪一步容易想错、哪类系统压根不适合用 REA以及我在实际项目中踩过的几个坑。适合正在做 ERP、进销存、财务系统或者被一堆业务表纠缠得想骂人的开发人员。1. 从零开始为什么我把业务系统拆成 REA 模型再写代码1.1 “订单表、发货表、收款表”这套传统设计到底缺了什么我复盘了一下旧系统的数据模型最典型的是销售模块订单表存客户下单信息发货单表存出库记录收款单表存到账金额加上订单明细表、库存流水表一共五张表。单看每一张表都没问题可业务上要回答一个简单问题——“这个订单从下单到回款花了多少天”就得跨五张表关联查询还得处理各种 null 和状态判断。传统设计的问题不是表数量多而是表结构不理解业务。订单、发货、收款本质上不是一个一个孤立的东西它们是一个事件链条客户下订单事件触发商品出库事件再触发资金入账事件。每一环都在改变企业的资源状态。表结构把“事件”拆散成了“状态快照”比如订单表里的 status 字段就从待支付变成已发货状态值被覆盖历史过程丢了。我想追一个单子的中间轨迹要么靠日志要么靠一堆冗余字段怎么都别扭。REA 视角把这一整件事还原成模型商品和资金是资源订单、发货、收款是事件客户和销售人员是代理人。它不先问“数据库要怎么建”而是问“业务发生了什么”。答完这个问题表结构反而是副产品。所以我决定用 REA 对销售模块重新建模并把建模过程做成一个可重复执行的小项目。1.2 从 ER 图到“事件为中心”的第一性转移过去我做设计第一件事是打开画图工具把实体画出来、加外键这叫实体关系模型也就是 ER 图。ER 图的优点是直观缺点是引导人关注名词而不是动词。你画了商品表、客户表、订单表心里想的是“有哪些东西”而 REA 强迫你想“哪些事件导致东西变了”。REA 模型只包含三类概念Resource 资源、Event 事件、Agent 代理人以及它们之间的关系。资源是经济资源比如库存商品、现金、应收款事件是被资源变化触发或产生资源变化的行为比如销售、采购、领用代理人则是参与事件的人或组织比如销售员、客户、供应商。核心关系有两种交换关系和转换关系。销售商品换取收款这是交换原材料经过生产变为成品这是转换。这个视角有个极其实际的好处数据库里的所有状态字段都能被搬进事件流。旧的订单表不再需要 status 这个枚举因为“已发货”本质上是“发货事件已经发生”。事件天然不可覆盖天然带时间戳天然可追溯。整套设计可以让每一个业务动作都成为一条不可变的记录而资源表只是对事件流做聚合得到的“当前值”。这个认知是我最终把项目命名为 rea 的出发点。1.3 工具项目的整体架构与选型理由最初我没有想写框架只是想着重构业务代码时能不能把 REA 的套路固化成代码。后来发现手动实现同一个逻辑太费劲还不如写成一个小工具。整体架构分成三层模型定义层、解析转换层、存储接口层。我用 Python 写原型。选 Python 不是因为性能而是因为 dataclass 和类型注解能很好表达资源、事件、代理人这类结构化定义开发效率高。解析层负责读取你写好的模型描述文件把它转成内部表示存储接口层再根据这个内部表示自动生成建表 SQL 和应用层接口。后来我把生成接口的代码抽出来作为基础库给新项目用。这个规模完全不需要引入重型框架一个 Python 包加一套约定就够。2. 实践拆解REA 三要素与事件流到底怎么落地2.1 怎么准确区分资源、事件和代理人刚开始用 REA 建模时最常犯的错误是把“单据”当成事件把“系统里的操作”当成事件。比如“创建订单”这件事业务里是用户点了提交按钮系统生成订单号但 REA 里真正的事件应该是“客户承诺购买”订单号只是这个事件的标识物。类似地“报价单”不是资源报价背后的服务和商品才是资源“审批”也不是事件审批通过后才产生正式的采购事件。我总结出一个很土但好用的判断标准资源是可以用数量或金额衡量的事件是发生在某个时间点的代理人是参与了某个事件的个人或组织。你需要判断代码里的每个实体到底能不能被“事件”改变。库存商品的数量可以被销售事件减少所以是资源客户信息可以修改名称电话但它是基本主数据客户本身不是资源客户手里持有的资金或者积分才是资源。可以体验一下这个判断方法把商品、现金、原材料、成品、优惠券放进资源把销售、采购、生产、领用、盘点、转账放进事件把员工、门店、客户、供应商放进代理人。这个清洗过程做完后续模型会非常顺。项目里我直接在 DSL 里定义了三类关键字model 解析器会自动检查你写的实体挂在哪一类下面类别不对就报错省了很多低级问题。2.2 事件与事件是怎么成对出现的REA 里比较特殊的一点是事件往往要成对建模。不是因为强迫症而是因为业务本身就是有来有回的。销售事件发生商品流入客户收款事件发生资金流入企业。这两个事件之间存在交换关系描述的是“我们拿商品换钱”。采购事件和付款事件成对生产事件内部则包含原材料流入和产品流出属于转换关系。在我的 rea 项目中我用一个 pairing 字段声明事件之间的关系。比如销售事件和收款事件之间可以明确写 paired_event: payment同时声明资源流向是 out 还是 in。这个关联在生成数据库时表现为一个可空的关联字段比如 payment_for_sale_id。它帮我解决了一个过去很头痛的建模痛点多张业务表之间的业务含义不明。你看一对事件的关系马上能说出“这是一笔销售换回了一笔钱”而不是看着 order_id 和 payment_id 发呆。注意事件成对不代表一张表里只能有两个事件。一笔销售可以拆成多次收款这时候一个销售事件会对应多个收款事件它们仍然共享同一个 paired 关系。我在工具里把这种关系记录在事件明细表 event_link 中支持一对多不会因为成对就限制死。2.3 外部参与者和内部参与者如何放进一张表里代理人内部再细分会掉进一个隐蔽的坑销售员、客户、供应商本质上都是“参与主体”如果分别建 table 会导致后续所有事件查询都要 join 多个表。REA 的正确做法是把所有参与者统一建模成 Agent然后用 Participation参与记录它们在事件中的角色。我的项目里生成了 agent 表字段包括 agent_id、agent_type 和显示名称。agent_type 区分 internal 和 external角色通过另一张 participation 表来描述。销售事件里销售员的角色是 seller客户的角色是 customer这两行都指向同一个 event_id。这样设计后我想查“某个客户最近接触的所有销售人员”只需要筛 participation 表不需要再拼十几张表。参与和事件的关系是显式的业务角色即使后续增加也不会改表结构。3. 核心实现用一个小工具把 REA 模型直接变成数据库表3.1 用 Python 数据类描述业务模型我先讲建模语言长什么样。为了让业务人员能看懂我用类似 YAML 的模型描述文件为了让解析器好处理我又把描述文件映射成 Python 数据类。一个销售模块的模型定义大致如下resource class Goods: name: str quantity: int location_id: str resource class Cash: currency: str amount: Decimal event class Sale: occurred_at: datetime goods: Goods agents: seller: Agent customer: Agent pairing: event Payment direction out event class Payment: occurred_at: datetime amount: Decimal agentes: customer: Agent pairing: event Sale direction in真实的 DSL 比这个复杂一点但核心就是我定义四种装饰器resource、event、agent、pairing。每个模型类都带上类型注解解析器可以检查字段类型是否属于资源或事件。这里有几件事必须说清楚。第一事件里的 goods 字段不是真实对象而是资源引用生成数据库时它会被转换成 event_resource 关联表不会把整个商品信息复制进事件表。第二agentes 这种定义在实际代码里应该是 Dict[str, Agent]上面的写法是为了展示方便。第三pairing 里的 direction 表达资源流向销售事件货物 out收款事件资金 in两个方向相反才构成完整交换。3.2 自动生成核心表结构与关联关系从模型到建表 SQL 的转换规则并不复杂真正关键的是把所有信息落到五张核心表上。第一张是 resource 表保存当前资源快照比如商品当前库存第二张是 event 表记录所有发生的事件必须有 event_type 和 occurred_at第三张是 event_resource 表记录事件改变了哪些资源以及资源数量第四张是 agent 表保存所有参与人第五张是 participation 表记录某个代理人在某个事件中扮演的角色。生成的 PostgreSQL 风格建表语句大致如下CREATE TABLE event ( event_id BIGSERIAL PRIMARY KEY, event_type VARCHAR(64) NOT NULL, occurred_at TIMESTAMPTZ NOT NULL, source_id VARCHAR(128), paired_event_id BIGINT, CONSTRAINT fk_paired_event FOREIGN KEY (paired_event_id) REFERENCES event(event_id) ); CREATE TABLE event_resource ( event_id BIGINT NOT NULL REFERENCES event(event_id), resource_id BIGINT NOT NULL REFERENCES resource(resource_id), direction VARCHAR(8) NOT NULL CHECK (direction IN (in, out)), quantity DECIMAL(18, 4) NOT NULL, PRIMARY KEY (event_id, resource_id) ); CREATE TABLE participation ( event_id BIGINT NOT NULL REFERENCES event(event_id), agent_id BIGINT NOT NULL REFERENCES agent(agent_id), role VARCHAR(32) NOT NULL, PRIMARY KEY (event_id, agent_id, role) );event 表里的 paired_event_id 是可空的因为第一个发生的事件通常还没有配对事件后续事件创建时可以反填它。在实际项目的数据库里我故意没有给 paired_event_id 创建硬外键后面会解释为什么。资源表我默认使用一个通用表 resource但允许子类。如果我定义了一个明确叫 goods 的资源工具会生成一个 goods 子表并让 resource 表的主键同时作为其主键相当于把通用属性和特有属性分开。这样做既保留了 REA 模型的统一性又不会让“库存位置”这种业务字段无处安放。生成代码时工具会检查每个资源子类是否有自己的属性有才生成子表。3.3 事件记录接口一个函数完成资源变动和轨迹留存工具自动生成的最有价值的部分是事件记录 API。我不需要在业务代码里手动写两段逻辑一段更新库存表一段插事件日志只需要调用一个函数让事件记录和资源变更发生在同一个事务里。函数调用大概长这样record_event( sale, occurred_atnow, resources{ goods: [{resource_id: 101, direction: out, quantity: 2}], }, agents{ seller: 3, customer: 88, }, pairing{ event_type: payment, }, )record_event 内部会做四件事第一在 event 表插入一行并带上 source_id 保证幂等第二在 event_resource 表插入资源变动明细第三在 participation 表插入参与角色第四根据资源变动的 direction 更新 resource 表里的当前数量。整个过程用数据库事务包裹失败回滚。实际测试下来这个方法让业务代码变得极其薄我的 service 层几乎只剩参数校验。考虑到有些项目不像我这样从零开始工具也支持“仅记录事件不同步资源表”。也就是说你可以把任意的库存表作为资源快照每次事件发生后手动调用一个同步函数。这让 REA 作为一个审计层嵌进旧系统成为可能不需要一上来就推翻所有表。4. 踩坑记录基于 REA 建模时最常遇到的 5 个问题4.1 多对多资源明细导致聚合数据翻倍我第一次用 event_resource 表时犯过一个低级错误把“一个事件关联多个资源”和“一个资源关联多个事件”这两件事混在一起。销售一个订单里有三种商品我在 event_resource 里插了三行这没错。但我同时又在 event 表里保存了一个 JSON 字段存整个订单的商品列表用于页面展示。结果做报表聚合时同样的商品数量可能被 JSON 展开再算一次数据直接翻倍。排查到最后发现是冗余存储惹的祸。解决方案不是删掉 JSON而是让 event_resource 成为唯一的商品明细来源页面展示时就查 event_resource 根据 event_id 聚合。我再也不相信那种“既能查询又能展示”的冗余设计除非你有一套机制保证所有读路径都统一走同一张表。4.2 事件配对关系的外键循环引用事件成对设计自然会产生循环引用销售事件指向付款事件付款事件又指向销售事件。如果给 paired_event_id 加上数据库外键约束插入第一个事件时就会遇到麻烦因为配对事件还没插入你只能先置空然后后续更新。这本身不难但加上严格的数据库约束后删除和调整顺序都会变得很痛苦。我的做法是不在 event 表上建立指向自己的硬外键只在应用层校验 pairing 关系。理由很实在paired_event_id 只是业务关联字段不是完整性核心。真正保证一致性的地方是冻结事件和后续聚合逻辑而不是数据库约束。如果你担心脏数据可以用一个后台任务定期扫描 mismatch 的事件对而不是插入时卡死。实际运行中这种“软关联”更灵活。4.3 退货、取消、冲销到底该用状态还是反向事件有一次做退货需求产品经理坚持要在订单上增加一个“退货状态”。如果按 REA 的思路就不应该去改订单状态而应该创建一个新的“退货事件”在这个事件里把商品数量以 directionin 的方式记录回资源同时把资金以 directionout 的方式记录出去。这样原来的销售事件依然是不可变的退货只是新发生的一个事件。刚开始同事们觉得“退货开一张新单子”很麻烦其实这个麻烦换来的是报表能力质的提升。你可以毫无压力地回答“净销售量是多少”因为只要用销售事件总量减去退货事件总量就能算出来你甚至可以追踪每一次退货对应的原始销售事件。不要删除历史事件这是我吃了亏才总结出来的铁律。4.4 资源余额是时点值但业务经常要区间累计REA 模型里资源表保存的是当前快照比如库存数量。但财务上经常要“本季度销售额”它不是某张资源表里的存量而是事件在时间区间内的累计值。我在 project 早期把销售额也做成了资源表里的一个字段并且每次销售时累加结果跨年核对时直接对不上。后来我意识到销售金额可以从 event_resource 表里按 direction 汇总出来。资源表永远只存当前存量区间指标全部用事件表聚合。为了让这个过程不太慢我加了一个物化视图计算每日资源增量再对增量做累计查询。这个调整让财务同事心头大石落地。记住存量放资源表流量放事件表别混着来。4.5 事件状态字段是反模式旧系统里几乎每张业务表都会带一个 status 字段待审核、已审核、已完成、已取消。REA 建模时一开始我也想给事件加 status但试了几次发现很别扭。事件是已经发生的事实事实不存在“状态”只存在“你有没有记录”。真正的业务审核动作应该建模为“审核事件”而不是把“已审核”写在原事件上。项目里我把事件都设计为 immutable如果要表达审批通过就创建一条“审批事件”关联到被审批的事件。这样数据的追溯链就很干净销售事件 - 审批事件 - 发货事件。每条事件都有自己的时间和责任人不会再出现一个字段被反复 update历史丢掉的问题。当然这个模型对开发者的纪律要求更高需要扭转“一个订单一张表搞定所有阶段”的习惯。5. 经验延伸REA 建模适合哪些系统以及如何渐进引入5.1 适合的系统和绝对不要硬上的场景从我实践下来的感受REA 建模最适合的业务是进销存、ERP、订单履约、供应链、财务和审计系统。这些场景的共同点是业务里有明确的经济资源有反复发生的资源流动事件并且需要回答钱和物的来龙去脉。在这些系统里REA 带来的追溯能力和事件驱动表设计能明显降低业务复杂度。反过来有些场景真的不适合硬套 REA。纯粹的内容管理系统、社交关系网络、论坛、评论系统本质上没有资源的经济流动把它们建模成 Resource/Event 只会让代码更绕。我会把 REA 当成业务交易域的设计工具而不是万能的建表规则。如果你做的只是一个收藏夹功能继续用普通的 CRUD 表就好不需要为了理论上的完整性付额外成本。5.2 如何在旧系统里渐进式嵌入 REA而不是推倒重来大多数项目无法接受一次大重构。我在某公司改造一个旧进销存时采取的是“新增事件日志层”的思路。先在数据库建一张轻量的 event 表和一张 event_resource 表然后把原有业务代码里所有关键写操作在旁边同步插入事件记录。商品库存表还留着但每次库存变动时我同时往 event_resource 里写一条方向相反的资源变更记录。这样旧逻辑不破坏新报表和分析可以直接基于事件表来做准确性比旧的流水表还高。等事件表的数据被验证可靠后再把旧表里的状态字段逐步迁出。连续跑了几周后业务已经不怎么依赖旧状态了。整个迁移过程中我没有写任何一条 ALTER TABLE 来大改旧表这让我在团队里少挨了很多骂。5.3 后续可以扩展的方向事件溯源与图谱接口rea 项目生成的事件表天然具备事件溯源的要素因为每条记录都不可变、带时间、带关联。我后来在此基础上加了一张 event_snapshot 表定期把资源快照存一下用于快速查询某个时点的库存余额。对于开始做报表和审计的团队这个快照表几乎是必需品。另一个有意思的方向是把 REA 模型转成图谱接口。既然资源、事件、代理人之间的关系已经显式建模我可以很轻松地生成一个“业务事件图谱”从销售事件出发通过 event_resource 找到商品通过 participation 找到客户和销售员再通过 pairing 找到对应付款事件。这个图谱用来做智能报表和业务分析效果比传统 join 好得多。项目走到这一步我最大的体会是 REA 不只是一个数据库设计方法它会倒逼你重新审视业务的本质。以前写代码我关心的是表和接口现在使用 rea 工具建模我关心的是“发生了什么、改变了什么、谁参与的”。业务部门的同事问我对不上账的问题时我不再翻几个小时的表而是打开事件模型一条条给他们看因果链路。这种思维上的转变比任何代码库重构带来的收益都大。如果你也想尝试我建议从一条最小的业务链路开始比如商品销售到收款回笼不要一开始就把全公司的模型都铺开。用我上面介绍的那五张核心表手动建一遍数据库再写几次 record_event 调用跑一周对账你就知道这套思路合不合胃口。反正这就是我当初一次性踩完所有坑之后决定把这个思路固化成 rea 工具的直接原因。