REA建模实战：售后备件管理系统的重构复盘

玩后端和业务系统时间久了你会发现一个规律大部分系统烂尾不是败在技术选型而是败在“大家对业务的理解永远对不齐”。技术团队说“你要的表我都建了”业务方说“数据没错但流程就是不对”。这种扯皮我经历过好几次直到后来在重构一个售后备件管理系统时认真用了一遍REAResource-Event-Agent才算是找到一套能让大家坐到同一张桌上讨论问题的建模语言。REA不是某个前端框架的缩写也不是检索系统里的什么名词它是一套源自会计领域的企业建模方法论核心就三个词资源Resource、事件Event、参与者Agent。听起来像是学术概念但真拿到项目里它比画ER图、建CRUD表要结实得多。这篇文章我从头复盘一次完整的REA建模实践讲清楚它到底解决什么问题、怎么一步步落到表结构和代码里以及我在过程中踩过的坑。适合做业务架构的后端开发、供应链和ERP方向的工程师以及被“需求评审会开成吵架会”折磨过的产品同学参考。1. 先搞清楚REA到底解决什么问题1.1 传统建模为什么总在“对不上账”传统的系统设计绝大多数是从“表”出发的。拿到需求先想着建哪几张表订单表、库存表、用户表、出库单表然后再拿外键把它们串起来。这种以名词实体为中心的建模方式有一个致命的问题它把“动作”和“结果”混在了一起。举个例子订单表里有一个状态字段待支付、已支付、已发货、已完成。看起来没问题但当你要回答“这个状态是怎么一步一步变过来的”“中间某个环节是谁经手的”“当时库存数量为什么是这个数”时状态字段完全帮不上忙。你只能去翻日志翻操作记录翻各种零散的流水表。业务上这叫“对不上账”技术上这叫“缺乏可追溯性”。你可能觉得加个操作记录表不就行了但注意操作记录表往往是后来补的、附属的它的设计逻辑是“为了记录而记录”而不是“业务本身就是这样发生的”。所以在我的经验里只要系统里核心业务是围绕资源流转的——资金、货物、库存、积分、资产——那么一开始建模时用REA这种以“事件”为中心的思路会比先画ER图稳妥得多。1.2 REA的三类核心概念与一个关键原则REA把整个业务模型压缩成三个基本元素听起来极简但表达力非常强。Resource资源不是指数据库表里的字段而是指业务上有价值、可被控制、能参与交换的对象。备件库存里的一个零件是资源账户里的余额是资源平台发放的优惠券也是资源。一个资源必须满足几个特征有稀缺性、可以被某个主体控制、能在事件中被消耗或创造。Event事件是资源发生变化的那一刻。出库是事件入库是事件支付是事件领用也是事件。事件是REA模型的核心它记录了“什么资源在什么时间、因为什么动作、变了多少”。事件一定是动词或者更准确地说是动词的名词化。Agent参与者是引发事件的人或组织。仓库管理员、维修工程师、外部维修商、系统自动任务都是Agent。Agent既可以是内部的也可以是外部的关键是谁对这个事件负责。这三个概念之间有一条最重要的原则我把它当作建模时的“宪法”来用资源只能被事件改变事件必须由参与者触发。换句话说你不能直接去改资源的数值所有变化必须通过一条一条的事件来体现。这条原则听起来很死板但它换来了一个巨大的好处任何资源的当前状态都可以通过重放事件序列来得到而且每一步都有据可查。我习惯把REA理解成“把会计思维带进软件建模”。会计上从来不会直接改账本上的余额每一笔余额变动一定对应一张凭证。REA就是这个思路的泛化它不只适用于钱也适用于货、服务、工作量、甚至数字资产。2. 一个完整案例售后备件管理系统的REA建模2.1 案例背景与需求梳理有一段时间我参与一个售后备件管理系统的重构。业务背景是这样的某公司在全国有多个备件仓售后维修工程师需要申请备件、领用备件、更换完成后把旧件退回或报废同时还有一批外部维修商也在参与他们也会领用备件但所有权归属、结算逻辑和内部工程师完全不同。系统上线大半年后最大的问题就是每个月盘点库存都对不上账面上说某型号零件还剩200个实际仓库里数出来只有160个中间差了40个谁也说不出这40个去哪了。我们团队一开始还在老路上修补——加盘点表、加调拨单、加异常处理流程但越补越乱。后来项目里有位长期做ERP的同事提了一句“你们这不就是典型的资源和事件模型吗先把模型理清楚再谈表。”我们于是推倒重来用REA做了整体建模。2.2 从业务流程到REA模型的推导步骤REA建模我总结下来就三步后来在很多项目里都用这套路数尤其面对已经有烂摊子的系统时效果比从头画几十张表清晰得多。第一步先画事件流不画表。把所有业务流程拉出来只找“动作”。在备件管理这个场景里核心动作是维修工程师提交备件申请仓管员审核申请备件出库工程师领用备件维修完成后旧件退回旧件报废或返修外部维修商领用备件定期盘点理货画完这张事件清单后先不要急着想“这不要建8张表吗”而是看每个事件到底让什么资源发生了变化。第二步标出每个事件对应的资源增减。备件出库意味着仓库这个Agent控制下的备件库存资源减少而维修工程师控制下的在途备件资源增加。旧件退回同理它把一个已领用的资源变成仓库里的待检旧件资源。注意这里有个容易迷惑的地方同样是“备件”在仓库里和在工程师手里是两个资源实例因为它们的控制主体不一样、所处的业务状态也不一样。第三步识别所有Agent并明确角色。这个系统里的Agent至少有四类内部仓库、维修工程师、外部维修商、系统自动任务。在多Agent参与的业务里一个事件往往关联两个Agent比如出库事件发出方是仓库接收方是工程师。这两个Agent维度在后续的统计报表里都要能单独过滤。完成这三步之后REA模型的骨架就出来了。我用文字描述一下核心实体关系不画图但这个结构非常关键Resource备件目录SPARE_PART、库存资源INVENTORY、在途资源IN_TRANSITEvent申请单事件REQUEST_EVENT、出库事件ISSUE_EVENT、退回事件RETURN_EVENT、报废事件SCRAP_EVENTAgent仓库WAREHOUSE_AGENT、工程师ENGINEER_AGENT、外部维修商PARTNER_AGENT每条Event都通过外键连接到一个Resource和至少一个Agent。2.3 从REA模型到物理表DDL参考REA模型最终还是要落到数据库表上。我当时的落地方案是核心事件表用PostgreSQLDDL尽量保持通用。下面给出几张核心表的简化版本完整字段我就不全贴了挑关键的部分说。-- 资源目录表定义资源的静态属性不存数量 CREATE TABLE resource_catalog ( resource_id UUID PRIMARY KEY, resource_code VARCHAR(64) UNIQUE NOT NULL, resource_name VARCHAR(128) NOT NULL, unit VARCHAR(16) NOT NULL, category VARCHAR(64) NOT NULL, is_tracked BOOLEAN NOT NULL DEFAULT TRUE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); -- 参与者表统一存人、组织、系统 CREATE TABLE agent ( agent_id UUID PRIMARY KEY, agent_code VARCHAR(64) UNIQUE NOT NULL, agent_name VARCHAR(128) NOT NULL, agent_type VARCHAR(32) NOT NULL, -- ENGINEER / WAREHOUSE / PARTNER / SYSTEM is_active BOOLEAN NOT NULL DEFAULT TRUE, extra_attrs JSONB NOT NULL DEFAULT {} );这张agent表是我特别想强调的点。很多团队会把工程师、仓库、外部维修商分别建三张表用各自的业务主键去关联。但从REA的角度它们在模型里的地位完全一样都是“参与者”只是类型不同。统一成一张表后续做跨维度统计时一个事件表就能覆盖所有角色不需要来回join多张完全没必要的表。事件表是核心中的核心我给出三种典型事件类型的共用数据结构-- 事件表所有资源变化都走这里 CREATE TABLE economic_event ( event_id UUID PRIMARY KEY, event_type VARCHAR(32) NOT NULL, -- REQUEST / ISSUE / RETURN / SCRAP / ADJUST resource_id UUID NOT NULL REFERENCES resource_catalog(resource_id), quantity_delta NUMERIC(14, 3) NOT NULL, from_agent_id UUID NOT NULL REFERENCES agent(agent_id), to_agent_id UUID REFERENCES agent(agent_id), occurred_at TIMESTAMPTZ NOT NULL, recorded_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), related_doc_type VARCHAR(32), related_doc_no VARCHAR(64), reason TEXT, created_by UUID NOT NULL REFERENCES agent(agent_id), CONSTRAINT chk_quantity_not_zero CHECK (quantity_delta 0) ); -- 每个业务单据头表关联事件便于按单据聚合 CREATE TABLE event_bill ( bill_id UUID PRIMARY KEY, bill_no VARCHAR(64) UNIQUE NOT NULL, bill_type VARCHAR(32) NOT NULL, status VARCHAR(32) NOT NULL, first_event_id UUID NOT NULL REFERENCES economic_event(event_id), created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );注意一个关键设计在REA落地方案里我尽量不在主表里冗余“当前库存数量”字段。库存数量应该是通过对事件表的quantity_delta做聚合算出来的。你可能觉得这样太麻烦每次查库存还要sum一整张表性能怎么办我的做法是事件表只保证绝对准确和可追溯另建一张库存物化视图或者投影表定期从事件表重算。具体在第四节说。核心原则是**事件表是不可篡改的事实源库存表是从事件派生的读模型。**如果写逻辑时直接去更新库存表那REA的整个意义就丧失了一半。从REA模型推物理表还有一个衍生收益因为所有资源变化都是新增一行事件而不是update一行库存所以并发控制变得非常简单。你几乎不会出现“两个人同时扣库存扣成负数”的问题每个事件都是一行新数据只要在事件表上做唯一约束就行。3. REA建模的实操方法与检查清单3.1 建模前的准备工作REA建模最关键的环节不在电脑前而在会议室。我踩过几次坑之后确立了一套固定的准备工作流程。第一访谈对象必须覆盖“资源生命周期”的所有角色而不是只找系统对接人。做售后备件系统至少要找仓管、维修工程师、财务、采购这几类人聊。尤其是财务财务对“账”的理解往往是全公司最清楚的他们能帮你确认哪些动作才算资源变化哪些动作只是内部操作不需要记录。第二把已有的纸质单据、表单、Excel台账全找出来。单据上的栏目名称往往隐藏着需求方默认的业务语义。比如一张领用单上有“领用人”“部门”“备件编号”“数量”几个字段你就能看到Agent领用人、Resource备件编号和数量的影子。这些单据是REA建模最好的原料比听口头叙述要可靠得多。第三给自己的模型设置一个边界。REA可以做得非常庞大从采购到付款到销售回款是完整一长条。但第一次落地时千万别贪多。我当时就只做“备件库存到领用退回”这一段闭环采购和财务结算都没碰先把最痛的对账问题解决。3.2 常见建模错误自检REA三条铁律在建模过程中我用三条铁律来做自我检查几乎每次都能揪出问题。铁律一Event必须连接Resource。有些事件看似是业务动作但没有资源变化就没有必要进REA模型。比如“维修工程师修改申请单备注”它不是资源变化不需要建模为经济事件。但如果这个修改导致申请的备件数量变了那么应该产生一个新的事件来记录这个变化而不是把原事件update掉。这一点很重要REA追求的是事情的“发生序列”不是单据的最新状态。铁律二Event必须连接至少一个Agent。事件是谁触发的哪个Agent的资源减少哪个Agent的资源增加如果回答不了这个问题说明资源类型或Agent划分有问题。比如“报废事件”看起来只涉及仓库一个Agent但它实际上把仓库的“待检旧件资源”清零了。如果连“旧件资源”这个概念都没建报废事件就没有资源可连那就说明建模不完整。铁律三Resource只能由Event改变不能被直接赋值。所有的库存调整、数量修正、移库操作都必须包装成某一个type的Event。盘点多了就建一个ADJUST事件quantity_delta填盘点差异数不要把库存表里的字段直接改掉。一旦开了“直接改数据”的口子整个可追溯性就崩塌了。我见过很多没弄明白这三条铁律的建模最典型的反例是把“借出”做成一个布尔字段借出等于true归还等于false。这就是典型的以状态代替事件。表面上看简化了但一旦你要回答“这个设备被借出过几次”“都是谁借的”只能查日志查不到数据。真正符合REA的做法是两条事件借出事件和归还事件设备当前是否借出状态可以通过事件推导。3.3 建模输出的物化与评审方法REA建完之后不能只停留在示意图上要有一套可评审的物化产物。我一般输出三件套。一是事件清单一张Excel或Markdown表格列出每一个Event类型包括事件名、涉及的资源、涉及的Agent、触发场景、单据来源。这张表用来和业务方确认业务覆盖度。二是资源-事件-参与者关系矩阵横轴是资源纵轴是事件单元格里写增/减。这张表用来检查模型的完备性比如“库存资源”这一列必须同时出现过“增加类事件”和“减少类事件”否则说明还有资源流转方向没覆盖。三是存量数据映射方案。老系统不是从零开始一定有历史库存和未完成单据。要明确哪些历史数据作为初始状态通过INIT事件一次性灌入哪些历史单据需要逐条转换成事件。这一步特别容易出问题建议单独给一周左右的时间做数据梳理和转换验证。在评审会上我会带着这三件套直接跟业务方说“你们别先看界面原型先看这些事件对不对。如果你们确认领用和退回这两条事件覆盖了全部场景那后面的表结构就不会有大问题了。”这种评审方式把讨论焦点从“长什么样”拉回到“发生了什么”效率提升非常明显。4. 落地过程中的坑与排查实录4.1 问题一事件表数据膨胀性能顶不住REA把所有资源变化都记成事件一个月下来表里很容易积累几百万行。如果每次算库存都直接对economic_event做聚合数据库肯定扛不住。我的解决方案是分两层。第一层事件表本身按时间做分区每月一个分区。查询历史事件按分区裁剪避免全表扫描。第二层建立库存物化视图周期性地从事件表重算每个资源的最新余额。实现上不用太花哨PostgreSQL的物化视图加定时刷新就够了-- 物化视图按资源所属agent聚合事件得到当前数量 CREATE MATERIALIZED VIEW inventory_balance AS SELECT e.resource_id, e.to_agent_id AS current_owner_agent_id, SUM(CASE WHEN e.from_agent_id IS NULL THEN e.quantity_delta ELSE 0 END) - SUM(CASE WHEN e.to_agent_id IS NULL THEN e.quantity_delta ELSE 0 END) AS balance_qty FROM economic_event e GROUP BY e.resource_id, e.to_agent_id;这个视图简化了一些场景因为有的事件是from和to都有值有的只从仓库出库到工程师情况更复杂一些。但思路是一致的运行时的查询都走物化视图事件表保持轻量插入。刷新频率根据业务要求备件库存这种场景每天凌晨刷新一次完全够用偶尔对不上账还可以手工重算。这里最需要注意的坑是不要让业务查询直接打事件表。你一旦要求所有查询都“绝对实时”就会被迫对事件表做高频聚合性能问题随之而来。REA不是银弹它把可追溯性做到了极致但实时查询成本高必须在架构上做好“事实源”和“查询模型”的分离。这个思路和CQRS、事件溯源其实是一脉相承的。4.2 问题二多Agent维度导致统计口径混乱备件系统里有内部工程师、外部维修商、仓库每种角色的统计口径不一样。财务要按维修商结算仓管要按仓库维度看库存售后主管要看工程师领用明细。如果直接在事件表上做各种group by很容易出现口径混乱。我采用的方案是在ETL层统一建一张事实表把所有维度都拉平。每个事件一行带上资源类别、from_agent、to_agent、发生时间然后BI和报表都从这张事实表取数。这样看起来多了一张宽表但口径是唯一的。还有一个小技巧为Agent增加“角色扮演维度”。同一个外部维修商在领用事件里是接收方在退回事件里是发出方。聚合时要用case when把from_agent和to_agent都映射到统一的“交易对方”角色上否则报表里同一个维修商会出现在两列里看着就别扭。很多BI口径混乱都是这个原因。4.3 问题三与旧系统对接时事件缺失老系统不是按REA建的它只有一个最终结果表比如“备件当前在哪个工程师手上”但历史事件链丢了。这种时候直接让新系统依赖老系统的存量数据会导致事件链从中间断开。我的处理办法是“事件补偿”把老系统的最终状态导出生成一条初始化事件作为新系统里事件链的起点。比如老系统告诉你有200个备件在某工程师手里我就生成一条INIT事件quantity_delta200to_agent_id该工程师备注里写明数据来源是“老系统第X次盘点导出”日期取导出的时间。后续所有新操作都从这条事件往下走。这样做有一个前提必须承认补偿事件的日期和真实业务发生日期有偏差。如果你的系统涉及严格的时间窗口统计这个偏差在对接过渡期里不可避免要在报表里留一个过渡标识字段方便后续追溯。4.4 一张避坑速查表整个项目做完我把自己踩过的坑和同伴踩过的坑整理成了一张速查表供后续项目参考。容易出错点影响推荐做法把状态字段当业务事实无法追溯历史链路用事件序列表达状态变化事件缺少Agent维度报表无法按人/组织分析每个Event强制关联from/to Agent直接更新资源数量字段对账永远对不上数量只能由事件聚合生成物化视图刷新不及时库存查询结果滞后明确业务容忍度设计合理刷新周期混合新旧口径的历史数据统计结果前后不一致补偿事件带数据来源标识一上来就想覆盖完整REA闭环项目拖太久没有产出选一个业务闭环先跑通这套避坑思路不局限于备件系统凡是涉及库存、资金、积分、工单流转的系统多少都能套用。在这类系统上验证过REA之后我个人的体会是它真正改善的并不是某一个接口性能或者某一条SQL而是让技术团队和业务团队共用一套“事件语言”。以后再有业务方跑来跟你说“这个数量不对”你第一反应不再是去查哪张表被谁update了而是打开事件列表一条条往下看看到底哪一步没发生。这个习惯一旦建立起来很多系统早期的隐性需求会被提前逼出来而不是上线半年之后变成事故再补救。如果后面还想再往前走一步我建议你把事件溯源的思路延伸到“请求追踪”上比如把用户操作也当作事件留存结合埋点数据做全链路分析。REA这套东西入门不难难的是坚持“所有变化都要有事件”的纪律。第一次应用不用贪多从一个库存闭环模块跑通你会很快体会到它的价值。