★ FEATURED ARTICLE 项目标题就三个字母rea。很多人第一眼看到会以为是什么“真实”“热点”的缩写或者干脆是某张旧图纸上随手起的代号。我最初拿到这个项目时确实只有“rea”这么一个代号没有完整需求文档也没有现成架构。要把一个只有名字的东西做成能跑、能交差、能经得起复核的系统第一步不是急着写代码而是先把“rea”拆开看它到底是“Resources、Events、Agents”三个词的骨架还是别的什么模型前缀这里补一个背景我做的项目属于业务数据建模一类核心诉求是有一套清晰的记账与库存追踪机制任何一笔状态变化都要能回查、对账、结平。常规的增删改查大法应付小 Demo 没问题但一旦涉及钱、货、权责、多方协作就会出现“余额和流水对不上”“审计时翻不出原始发生记录”这类经典事故。踩过几次之后我越来越倾向于一种事件驱动的经济本体模型也就是 REAResource 资源、Event 事件、Agent 参与主体。这篇文章就围绕“rea”这个项目代号把它的设计思路、建模要点、最小原型实现、踩坑实录和取舍过程全部拆开讲。适合正在做库存、财务、交易状态流转的同学也适合那些拿到一个模糊需求后不知道如何落地的人。1. 内容整体设计与思路拆解1.1 为什么我不直接建表而是从“事件”开始传统业务系统拿到“REA”这种模糊诉求第一反应通常是建三张表资源表、事件表、主体表然后写一堆 CRUD 接口谁都能往表里灌数据。这本质上是把关系数据库当记事本用表面上字段齐全实际上缺失了对业务语义的约束。比如说“卖出商品”这个动作直接往库存表减去一行、往资金表增加一行看似完成了记账但今天减库存的是操作员明天加资金的是另一套系统两个动作之间没有强关联到了月末对账必然破绽百出。这给我们的第一个关键结论从事件入手。库存、余额、积分、额度都是事件发生后沉淀的结果而不是事件发生的源头。项目代号“rea”里的 E 排第二恰好暗示了事件在模型中的核心位置。任何业务操作都应该被记录为一个经济事件而不是一个直改状态的接口状态只是这些事件累计出来的投影。1.2 REA 把业务世界拆成了三种对象REA 模型最早的形态来自会计领域的思考想解决的就是“会计科目和业务实际发生之间严重脱节”的问题。常规记账法下一笔交易被拆成借贷两个科目今天看没问题但隔了三个月再回查往往没人能说清楚这笔账对应的是哪一次采购、哪一次发货。REA 的核心拆法是把现实世界切分成三类Resource 资源有价值的物品、服务、资金、容量、人力。它强调可用性而不是一个死板的科目。Event 事件经济活动中发生的具体动作比如“入库”“发放”“支付”。它是模型的核心不可被覆盖只能追加。Agent 参与主体买卖双方、企业内部部门、合作伙伴以及任何能发起或接收资源的实体。放到当前项目里资源可能是库存商品、现金账户、积分池事件可能是销售、收款、退货、采购入库主体可能是客户、仓库、经销商。这个三角结构把“谁动了什么资源”和“在什么时候动”全部绑在一起比一摞互相割裂的数据表要稳妥得多。1.3 “rea”作为项目代号给我们的设计约束项目只有三个字母却让我意识到一件事代号越短往往意味着需求边界越模糊越是不能黑盒式自由发挥。我定的设计约束包括任何一条记录一旦写入不能物理删除只能通过反向事件冲正。资源余额永远是“按事件聚合”算出来的而不是独立存储后人工维护。所有涉及双边的动作比如采购与付款、发货与收货必须有配对关系或可追踪的凭证链。模型允许事后查证“我现在还剩多少库存/余额”但绝不允许绕过源头记录直接改写余额。这些约束不是拍脑袋定的而是围绕“rea”的三个字母在业务语义上的隐喻延伸Resource 代表资产视图Event 代表事实真相Agent 代表责任归属。缺少任何一个整个模型都会出问题。2. 核心细节解析与实操要点2.1 四个建模顺序先定义动作再定义资源最后谈主体很多项目在建模时习惯先拉一张大 Excel把所有业务字段堆上去再按部门划分。我不建议这么做。实际操作中我先按“经济事件”梳理业务流程。以当前项目为例业务链上有采购、入库、销售、收款、退款、计提库存损耗等环节。把事件清点完再给每个事件涉及的资源编码最后才把主体关联上去。之所以把事件放在第一位是因为事件具备“动作标识”例如增量或减量而这天然决定了资源账户的变化。如果先定义资源表再回头补事件容易出现思路上反复横跳最后建出一堆没有明确语义的中间状态表。项目编码阶段我用事件名作为聚合根命名资源表反而只是事件表的一个维度标签。2.2 双边关系的配对为什么一笔交易必然变成两个事件真实业务流程里几乎不存在单方动作。客户付款供应商才确认发货仓库出库订单才变成已完成。常规系统经常只记录“库存减了”却没有同时记录“应付账款减少”或“现金账户增加”。在 REA 模型中双边交换被表达为两个相互关联的事件一方提供资源比如销售方“发出商品”。另一方接收资源比如购买方“收到商品”。两者配对后才形成一个完整的“经济交换”。不要小看这个配对约束。如果系统只记录事件但不做配对会出现“有出无入”或“一货多卖”。我在当前项目里给每个事件增加了一个“对偶事件引用”字段保证一次买卖有明确的资源流向。这样后续做应收应付、库存占比、毛利润分析时都可以按配对关系聚合不需要再去杂乱的流水表里猜。2.3 增量、减量和库存状态的闭环资源余额计算不要直接维护字段。当前项目里所有库存和资金余额都由事件表通过“按资源分组、按时间聚合”得出。从建模角度我把所有事件分为两大会合方向资源流入采购入库、退款入库、期初导入、调拨入库。资源流出销售出库、损耗出库、退货出库、盘点调整。这两类方向会被记录成事件类型属性而资源当前结存只是“流入总量减流出总量”的结果。这样做的一个额外好处是可以对任意时间点做区间快照。只要把截至某日的事件聚一次就能得到当日的库存或余额而不是靠一张 status 字段死扛历史版本全被覆盖。2.4 身份、时间戳和幂等设计是三条保命防线在实操层面有一件小事逼出了后面的可靠性设计并发下同一资源被两条事件同时变更。比如用户同时下单和后台手动调库存如果事件表设计得不够稳库存结存就会被算错。解决办法不是给数据库加一堆悲观锁而是给事件唯一性加上“事件 ID 来源业务单号 资源 ID”的复合约束并在写入事件前做前置校验。得专门强调时间戳的问题。REA 中“事件发生时间”和“系统记录时间”是两回事哪怕只差了两秒钟在月底对账时也可能造成巨大困惑。我当前项目的做法是业务时间由上层传入记录时间由存储层生成并明确把两个时间字段都暴露在查询结果里。很多读者一开始觉得这是画蛇添足真到审计时才发现这根分界线救了大命。每个环节的实操要点我最后整理成了一张速查表供日常开发时对照。建模环节关键动作禁止事项事件定义先列业务动作再分配事件类型不能把状态字段当成事件资源定义统一资源 ID 与单位不能在事件明细里存冗余金额而不存数量主体定义明确买家、卖家、仓库角色不能让主体直接改资源结存配对逻辑建立对偶事件引用或凭证号关联不能只记一边丢另一边余额计算按事件聚合生成投影不能直接 UPDATE 余额列3. 实操过程与核心环节实现3.1 用代码把三类对象表述出来这个项目我采用的是追加式存储方案存储结构相对简单。很多人问为什么不用关系表直接存“当前余额”答案是余额是可变状态事件是事实。事实只能累积状态可以从头重新推导。如果有一天发现某个余额算错了只要修正事件流重新跑一遍聚合就能找到问题。先把基础类型定义出来。我用的是 TypeScript 风格但思路在任何主流语言里都能平移type Resource { id: string name: string unit: string // 计量单位 } type Agent { id: string name: string } type EconomicEvent { eventId: string eventType: INFLOW | OUTFLOW | ADJUST resourceId: string quantity: number occurredAt: string // 业务发生时间 recordedAt: string // 系统记录时间 providerAgentId?: string // 流出方 receiverAgentId?: string // 接收方 pairedEventId?: string // 对偶事件的 eventId sourceBizNo: string // 来源单据号用于幂等 }这里没有把“余额”放进去。资源余额会被视为一个投影值后续通过事件聚合生成。这样做的好处是每当有人问我“这个资源到底有多少”我只需要跑一条聚合指令而不是去看一张可能被某段代码偷偷改过的余额表。3.2 核心聚合逻辑与不变量检查有了事件定义之后核心逻辑就是“写入前检查写入后聚合”。我当前项目采用的是事件表追加写入但在写入前必须做两个检查资源是否存在避免把事件挂在幽灵资源上。该业务单号是否重复避免并发下的重复记账。聚合计算本身不复杂按资源分组把流入事件数量相加减去流出事件数量就得到当前结存。但有一个隐藏细节必须注意事件里除了数量有时还会带金额、积分、税率等附加字段。附加字段不应影响资源结存的计算口径否则容易把数量口径和金额口径混在一起。比如库存余量只看数量应收货款看金额两者可以来自同一条事件但聚合口径完全独立。对应的聚合代码大致是function projectResourceBalance( events: EconomicEvent[], resourceId: string ): number { return events .filter(event event.resourceId resourceId) .reduce((balance, e) { return e.eventType INFLOW ? balance e.quantity : balance - e.quantity }, 0) }这段逻辑简单到看起来不像核心代码但整个系统的信任恰恰建立在“所有业务动作都走事件写入而不是绕过事件直接改资源”之上。我在项目里专门加了一道防线仓库管理员和外部系统的写权限都被收窄到“只能新增事件”不允许对资源和余额表执行更新语句。3.3 把一次销售流程串成完整事件链现在用一个最容易理解的销售场景演示完整链路。客户下单支付货款仓库发货。在传统系统里这三步被拆成订单状态、支付状态、物流状态彼此之间靠状态机维护。在“rea”项目的 REA 模型里它们被表达成三个相互关联的经济事件客户支付时记一笔资金资源减流入不是“客户资金流出”但站在系统主体视角应该是“现金/收款账户资源增加”。仓库发货时记一笔库存资源减少。交易完成时建立销售事件与收款事件的对偶关系。需要注意这里的“现金账户资源增加”是站在企业主体视角。如果站在客户视角则会让客户资源减少。所以模型中的主体角色非常关键。资源流动必须体现“谁给出、谁接收”的责任关系这样才能支持后续的应收应付分析。我在实现时会让客户订单和收款单通过“sourceBizNo”字符关联而不是只靠时间戳猜。实际踩坑后发现如果没有 bizNo 关联仅仅按时间顺序配对退款单和正常订单会大面积错配后续对账直接崩溃。3.4 校验逻辑如何判断事件流“结平”了业务事件写入容易但怎么判断事件流没有重复、没有漏记我给当前项目设计的办法是把“双边配对”作为校验核心。每一条资源流出事件都应当能找到一条对应的接收事件或对偶事件否则系统就标记为“未完成交易”。这里引入了一个“事件链结平”的概念针对某笔订单流入的资源总量与流出的资源总量在扣掉合理损耗后应当保持一致。比如采购 100 件商品入库销售出库 90 件调拨出库 5 件盘点调整损耗 1 件剩余预期库存应为 4 件。如果事件聚合得到的结存是负数说明发生了擅自出库或重复发货必须立即阻断。我把这个检查做成了定时任务每晚扫描一次所有资源事件的聚合值并把负数结存、未配对事件、同源重复事件统一输出成预警报表。这套报表在项目交付时成了最亮眼的成果因为财务侧可以直接拿它做日结检查而不是再人工核对 Excel。4. 常见问题与排查技巧实录4.1 问题一事件表越来越大聚合越来越慢这是“rea”项目上线后第一个被问爆的问题。事件表按天累积全量扫描聚合确实会变慢。解决办法不能靠关停系统而是要做时间分区和预聚合。我把事件流水按月份分区并把“资源每日结存”预聚合到一张快照表。日常查询先读快照再补当日增量事件。跨月对账时直接读每个月最后一天的快照而不是从头聚合几百万条事件。这种做法的前提依然是“事件是事实源快照只是缓存”。缓存可以随时按事件流重建因此不需要担心预聚合表被破坏带来的灾难性后果。对我来说这一层设计让性能和可审计性达到了平衡。4.2 问题二把“事件”当成了“更新余额的入口”有段时间我在引入外部接口时走了弯路接口逻辑直接传入“调整后的剩余库存5”然后系统把库存改成 5。这实际上是在做状态覆盖而不是事件记录。发现问题后我把接口改成传入“调整原因盘点差异2原结存3新结存5”由系统生成一条“盘点调整”事件。虽然多写了一步但整个调整过程变成可追溯链条为什么从 3 变成 5责任主体是谁来源单号是什么全部有据可查。这种问题很有代表性因为常规思维的惯性是先算结果再写状态而 REA 要求先记录动作、再推导结果。我在项目内部定了一条铁律任何“修改余额”的实现都直接打回必须改成“新增事件”。4.3 问题三双边配对关系反复错乱项目早期我对配对关系的实现不够严谨导致一批订单在退款后出现资源重复回流。排查过程发现代码里通过“相同订单号”匹配资金流和物流事件但支付分单、退款分单场景存在一对多关系订单号根本无法唯一标识事件对。排查思路是把配对关系抽象成独立概念一次业务交易可能由多个事件组成。我先建立“业务交易”表再把相关事件挂到交易下。这样无论支付多少次、退款多少次都能在交易维度上汇总而不是傻傻地试图让每个事件都有一个唯一对偶。这个改动后来被证明是项目里最值得的一笔重构。4.4 问题四负数结存被忽略月底才发现严重超卖很多团队对负库存的态度是“先出库事后补票”项目初期难免有类似情况。排查时发现根因是结算状态和实物库存状态没有严格分开。应用层查询虽然使用了聚合函数但某些报表直接读旧余额字段导致负库存不会阻断出库。最终给这个坑的解法是在事件写入前做一个“前置不变量检查”如果是库存类资源的流出事件且聚合结存减去本次流出数量小于 0系统直接抛错。这个检查全程在事务里完成不能放到异步任务里。异步检查只能用于事后告警不能用于事前拦截。4.5 问题排查速查表现象可能的根因排查方法解决办法库存越算越多新增了流入事件但没走幂等按 sourceBizNo 查重复事件加复合唯一索引结算余额为负只记流出忘记关联收款按交易维度看事件链强制配对后落账月底数据对不上历史事件被物理删除检查事件表删除日志禁用物理删除只允许反向冲正报表速度慢全量聚合且无快照查执行计划按月分区 快照表退款错误配对关系基于单一单据号打印交易维度关系链引入“业务交易”聚合层5. 方案取舍与现实扩展REA 不一定每次都全量上马5.1 什么时候用完整 REA什么时候用简化事件模型很多人问我是不是所有业务系统都该把 REA 当金科玉律我不这么认为。REA 适合具备“双向交换、可审计、多方责任”的领域比如电商订单、库存调拨、积分交易、供应链协作。如果项目只是一个内容管理后台、内部通知系统没有明显的资源和责任流动强行引入 REA 属于过度设计。当前项目里我也做了简化处理没有引入复杂的分类账而是保留了“资源、事件、主体、交易”四张表把完整 REA 中的许多细分科目做成了资源表上的附加属性。这么做在中小系统里更灵活又不会牺牲审计能力。核心判断标准只有一条你能不能回答“每一条业务记录为什么存在、由谁负责、从哪个状态变到哪个状态”。能回答简化版就够了回答不了就说明需要完整的事件链约束。5.2 把 REA 和事件溯源、领域建模组合起来“rea”项目的另一条演进路线是彻底引入事件溯源把事件表作为唯一事实来源把所有业务查询模型做成只读投影。这个方向和 REA 天然契合因为 REA 中的事件本质就是领域事件。落地时可以保持基础事件不变量不变只额外增加订阅和投影层把资源余额、应收账龄、月度毛利分别投到不同的读模型里。注意一点如果整个过程全部走事件溯源丢弃普通数据库里的业务表团队的学习成本会陡然上升。对于一个还没建立成熟监控体系的项目我建议渐进迁移先把核心交易和库存切换到 REA 事件模型报表和数据仓库仍然从投影层取数不要一上来就推翻所有模块。5.3 后续扩展库存批次、追溯码与权责对账当前项目做完之后我又在原模型上追加了两个扩展批次追踪和责任权属。这批资源是哪个批次入库批次对应的采购事件是什么哪个主体在哪个节点接收了资源都通过资源 ID 和配对事件串成关系链。一旦出现质量投诉只需要按资源 ID 反查事件链就能定位到具体批次和供应商而不用翻拍脑门式报表。这套能力背后的完整模型复杂得多但 reader 可以照着本文的思路先搭最小闭环。等到业务量级和团队理解力都上来之后再去补上会计科目级矩阵、预算控制、多币种折算这些更专业的细节。越早把 REA 的基本骨架立住后面的扩展就越顺。6. 结尾分享我对“rea”这个项目最深的体会是一个模糊的代号反而逼出了最干净的骨架。当你没有冗长需求文档可以依赖时你只能依靠领域常识去追问三个问题这里有什么资源在流动什么事件会改变资源状态谁有责任对这个事件负责这三问看似简单却足以过滤掉百分之八十的烂设计。如果你也正拿着类似“rea”这样含义不清的项目代号我的建议不是立刻去问产品经理要文档而是先拿出一张白纸把业务的资源项、事件项、主体项列出来再把它们之间的流向画出来。你会发现大多数复杂的业务关系都会被压缩成一个可追踪的事件链。只有看过完整链条之后再决定用哪套表结构、做不做快照、要不要引入事件溯源。真正确认资源、事件、主体三者关系的那个下午我就知道这个项目后面的路不会太歪。希望这篇从头拆到收尾的记录也能给正在做库存、账务、交易系统的你一点实操层面的参考。
阅读完成 · 觉得有帮助？
