从接手一个只有三个字母、没有任何说明文档的代号需求开始这场折腾给我上的课比很多完整的项目都多。上个月部门里丢过来一个内部需求代号就叫 rea。最初我以为是随手敲的缩写翻了半天背景资料发现需求方想做的事情其实一句话能说清把“客户下单—仓库发货—财务收款—偶尔退货”这套业务从 Excel 里彻底搬到系统里。真正动起手来才发现难的不是写接口而是业务数据该怎么建模。团队里有人提议沿用传统记账的科目表有人想直接维护库存余额字段吵了两轮以后我决定把 REAResource-Event-Agent资源-事件-主体建模方式引进来。这篇文章就是记录我们怎么用一个看似学术的模型把一套真实业务流拆成了干净、可追溯、能对账的数据结构。如果你也在设计进销存、订单、财务相关系统或者纠结“到底要不要上事件溯源”这份经验应该对你有参考价值。1. 为什么一个小项目会从“记账”改成“REA事件建模”1.1 原始诉求一张流水表再也撑不住了需求方最早的方案特别简单就一张流水表时间、类型、数量、金额、库存余额后面再补几个字段发票号、客户、仓库。这套设计在业务量小的时候完全能用但等到“先发货后开票”“一张订单分三次发”“客户退回一部分再补发一波”这些真实情况出现表就开始崩塌了。最典型的问题有两个。第一同一笔业务被拆成多行之后余额字段互相覆盖。比如 6 月 3 日发货 100 件库存余额扣了 1006 月 8 日退货 10 件余额又加回 10。看起来没什么问题但要查“这 10 件退得到底是哪一单的”流水表给不了答案只能靠人工比对。第二财务要看“应收账款”销售要看“在途订单”仓库要看“待发库存”同一张流水表要同时满足三种口径字段得越加越多最后谁也不信谁。当时我统计了一下那张表在需求阶段已经被扩展过四轮。我判断问题不在表不够宽而是从一开始就把业务的“过程”压成了“结果”模型选错了。我们需要的不是一张记录余额的表而是一张能回放业务过程的表。1.2 借贷记账法的三块短板团队里财务背景的同事主张用传统借贷记账一张凭证表加上科目字典然后靠借贷方向来表达资源流入流出。这套体系确实成熟也解决了余额混乱的问题但它有三块短板在咱们这种偏业务系统的场景里格外扎眼。第一科目对非财务人员不友好。“应收账款”“预收账款”“主营业务收入”每个科目背后都有一套会计准则解释业务人员根本不知道发货该记哪个科目。需求方每次提需求都要先问一句“这个属于收入还是往来”沟通成本非常高。第二借贷记账天然压缩过程。一笔销售凭证最终呈现的是“借应收账款 / 贷主营业务收入”但发货和收款之间的时间差、分批发货的状态流转、退货冲销的路径全被压缩没了。第三扩展性差。业务一旦出现新玩法比如“预充值余额抵货款”又得生造一个新科目报表逻辑、凭证逻辑全部跟着改。表格对比一下会更直观对比维度传统借贷记账REA事件建模记录焦点科目金额变动资源、事件、主体的关联业务过程被压缩成凭证结果完整保留事件链条业务人员理解成本高需要懂会计科目低动词和名词直白新增业务类型的成本需新增科目和凭证逻辑新增事件类型即可对账方式借贷平衡校验事件流汇总投影1.3 REA的一句话解释REA 不是什么新东西学术圈提了很多年核心就三件事先说清楚业务里有哪些资源比如商品、现金、库存然后定义会发生的事件比如发货、收款、退货最后再标记主体也就是谁参与进来客户、供应商、仓库员、财务。传统建模方式是“先定科目再填数”REA 的思路是“先描述业务在发生什么再根据事件反推财务影响”。我们最终决定在数据层用 REA 建模传统借贷逻辑仍然保留但只放到报表投影层。这样业务系统演进的时候不会被会计科目绑死财务报表又能通过视图随时还原。这个决定后来被验证是对的但前提是先把概念吃透。2. 先啃概念资源、事件、主体的边界到底怎么划2.1 一套简单实用的判断口诀模型听起来简单真正开始建模团队讨论最多的问题就一个字这个名词到底算资源、事件还是主体我后来总结了一套判断口诀基本能解决 80% 的争论。资源是能被交换、储存、转移的东西通常有数量、有状态并且在企业经营中是“稀缺”的。库存商品是资源银行存款是资源应收账款这种“对他人的索取权”在 REA 体系里也可以抽象为一种资源。反过来“销售机会”“客户意向”“订单”这类东西不是资源它们是过程或承诺没有独立的资源流。事件是改变资源状态或主体责任的业务动作通常是动词或动名词到货、发货、收款、付款、退货。关键判断标准是“是否是原子动作”。如果一件事还能继续拆成更细的动作那要么是它定义太粗要么它本身是一个聚合而不是事件。比如“销售”不是事件因为它是多个事件的组合下单、发货、收款。主体是参与事件的内部部门、人员或外部客户、供应商。主体的核心价值是承载责任关系通过事件我们能知道“谁欠了谁”“谁向谁交付了什么”。2.2 用四个业务动作验证边界光讲口诀有点虚拿采购到货、销售发货、收到货款、支付货款四个动作来实际操作一遍。采购到货涉及资源是货物事件是“到货”主体是供应商和仓库员。销售发货资源是库存商品事件是“发货”主体是客户和仓库员。收到货款资源是银行存款事件是“收款”主体是客户和财务。支付货款资源是银行存款事件是“付款”主体是供应商和财务。这个事情看起来简单但真到梳理的时候有一个特别容易踩的坑把“订单”和“事件”混在一起。订单本身不是事件它是事件发生的依据或者说是一种承诺。我们处理的办法是单独建一张销售订单表订单状态只表示业务单据的流转状态而真正影响资源和责任的记录全部走事件表。一张订单的“创建”事件可以没有资源流这只是记录承诺发生不改变库存也不产生应收。2.3 两条关联规则帮我避免“随心所欲建模”REA 建模最怕的就是每个人按自己理解建一套最后模型分叉。我在团队里强制要求遵守两条关联规则效果很好。第一条一个事件至少有一条资源流入或流出。如果一个事件没有任何资源流那它大概率不是 REA 里值得建模的事件或者它只是状态标记。这条规则保证了我们不会把一堆“空事件”塞进系统。第二条一个事件必须同时连接内部主体和外部主体。发货这件事不能只有仓库员还必须连向客户收款不能只有财务还必须连向客户。这条规则把经济责任找出来了。举个例子如果某天业务提出“内部调拨”你会发现问题来了调拨只有一个内部仓库员没有外部主体资源从 A 仓库流到 B 仓库但没有经济责任转移。这时候就不该用“调拨事件”概念硬套而应该把调拨实现为两个不同仓库的资源流方向记录或者干脆把它放行成一个特殊类型避免它污染正常的责任关系网络。这条规则的价值在于它逼着你把每一种新业务动作先放在“资源流责任”框架下检验一遍而不是急着加字段。2.4 边界模糊的三个高频问题踩过几次坑之后我把最容易混淆的三个问题单独列了出来。问题一订单算资源吗不算。订单是承诺凭证它的创建不改变任何资源存量只产生“将来可能发生”的信息。REA 模型里可以把它作为事件组的抬头但不该把它放到资源表里参与资源余额计算。问题二库存余额算资源吗不算。资源是商品本身余额是“当前时刻的库存快照”它可以通过事件流重新计算。如果你把余额表当资源去建模就等于同时维护两套真相迟早会出现不一致。问题三合同为什么也不是资源合同约束未来的资源流但它本身不能交换、不会耗用。我一度把合同建模成资源结果所有报表都开始出现奇奇怪怪的“合同余额”后来才意识到应该把合同编号作为事件的属性而不是把合同本身当节点。3. 把购物订单拆成 REA 模型一张关系表的设计全过程3.1 选一个最小闭环理解了概念以后我没有急着把所有业务全部灌进 REA 模型。范围太大一定会翻车所以我挑了最小闭环客户下单、仓库发货、财务收款、客户退货。这个闭环已经覆盖了大部分进销存系统的核心又足够验证模型是否好用。最小闭环的好处是出问题你能精准定位是设计问题还是执行问题。如果一开始就把采购、调拨、盘点、报废全铺开模型好坏根本分不清。3.2 五张核心表的初始设计我们最终落地的表结构没有搞那种极简到什么都装 JSON 的偷懒设计也拒绝了把每个业务动作单独建表的重复劳动而是让表的数量保持在五个第一张资源表 resources。字段包括资源ID、资源类型product、cash、receivable、名称、SKU、规格、单位。资源表统一管理所有可以在业务中被交换的标的物。第二张事件表 events。字段包括事件ID、事件类型order_created、shipment、payment、return、业务单据号、发生时间、状态、备注。事件表是整个模型的核心所有业务行为都落在这里。第三张主体表 parties。字段包括主体ID、主体类型customer、supplier、warehouse_keeper、finance、主体名称、联系方式。主体表留存参与各方的信息。第四张事件资源流表 event_resource_flows。字段包括流水ID、事件ID、资源ID、方向in/out、数量、单价、金额。这张表是资源变动明细也是库存余额和应收余额的来源。第五张事件主体角色表 event_party_roles。字段包括角色ID、事件ID、主体ID、角色customer、warehouse_keeper、finance 等。这张表把每个事件关联到具体的主体和角色上。这五张表的分工很清楚事件负责“发生了什么事”资源流负责“东西怎么动”主体角色负责“谁参与了”。任何一张业务单据都能拆成“1 条事件 n 条资源流 n 条主体角色记录”。3.3 为什么事件不直接挂“业务单据”设计的时候有成员提出过方案直接在事件表上加一个 sales_order_id 字段把订单信息塞进去。我否掉了这个方案原因是我们把销售订单作为一个聚合单据管理它的状态包括待审核、已审核、部分发货、已发货、已完成这些状态属于单据自身流转不该塞进事件表里。所以最终方案是单独保留订单主表订单表只负责记录订单头和订单明细事件表通过 order_id 关联到订单。这样业务人员看订单有订单视图财务对账有事件视图两边不互相污染。我用一句话解释这个设计订单是业务单据事件是事实记录。单据可以被修改、被作废、被重新审核事实记录一经写入就尽可能不变。如果把两者放同一张表要么单据修改连累事实要么事实锁死单据。3.4 一个完整例子100 件商品从发货到回款拿一个具体例子走一遍模型。假设客户会禾商贸虚构代称下单购买了某型号商品 100 件每件含税价 120 元总额 12000 元。订单创建事件本身没有资源流但我们记录了一条事件类型为 order_created 的记录并关联主体为客户、销售员。随后发货事件表新增 shipment 事件资源流表写入一条记录资源ID 为该商品方向 out数量 100金额 12000。同时应收增加严格来说应收账款是一种资源发货后应该产生一条方向为 in 的 receivable 资源流。为了保证对账方便我们没有把应收建模成“只在收款时冲减”的单向资源而是每个业务事件都明确产生对应的资源流。然后客户退货 10 件事件表新增 return 事件资源流表写入两条产品资源方向 in数量 10金额 1200应收账款资源方向 out金额 1200。最后收款 10800 元事件表新增 payment 事件资源流表写入银行存款资源方向 in金额 10800应收账款资源方向 out金额 10800。这一串下来整个交易过程被完整记录。任何时刻都能回答这个客户累计买了多少、退了多少、付了多少、还欠多少不需要依赖任何手工台账。3.5 关系数据库里的约束细节模型看着简单落地时有一堆细节不处理的话数据会很快脏掉。数量字段必须有检查约束不允许为 0。金额单位统一用最小货币单位比如分避免浮点误差。我在第一版设计里用了小数后来对账差了几分钱排查半天才发现是浮点问题。业务时间用 occurred_at 而不是数据库的 created_at。补录历史的场景下created_at 是录入时间会打乱时间线必须单独记录业务实际发生时间。幂等键很重要我用“业务单号 事件类型 事件序号”作为唯一键防止接口重试或消息重复消费时把事件写两遍。4. 从模型落到代码事件溯源式的流水记录实现4.1 为什么我不直接更新余额很多库存系统的第一反应是库存余额字段收货 10发货 -10完事了。REA 模型的写法则完全不一样发货不是“扣库存”而是“记录一条发货事件再让余额由事件流重新计算”。听起来绕但好处是实打实的。首先历史可重放。余额错了不需要靠日志去猜当时是哪个操作改坏的直接重算事件流就能得到正确的余额。当时项目上线后出现过一次人工补录错误如果是传统余额表得写一堆临时修复脚本因为我们是事件流直接把那条错误事件标记作废再重新投影就恢复了。其次业务与余额解耦。以后加新的业务类型不需要为“盘点”这种动作专门写库存更新逻辑只要定义新事件类型投影规则里加一条分支就行。最后这套模型天然有审计价值谁在什么时间对什么资源做了什么全都能追溯。4.2 事件写入的核心代码思路代码层面的核心就一个函数记录事件。它的输入包括事件类型、资源流列表、主体角色列表、业务发生时间、业务单号、元数据。一个函数完成“写入事件 写入资源流 写入主体角色”三件事并且全部包在同一个事务里。下面这段伪代码基本能表达写法def record_event(event_type, flows, party_roles, occurred_at, business_no, metadataNone): with db.transaction(): event_id insert_event( event_typeevent_type, occurred_atoccurred_at, business_nobusiness_no, statuscommitted, metadatametadata, ) for flow in flows: insert_event_resource_flow( event_idevent_id, resource_idflow[resource_id], directionflow[direction], quantityflow[quantity], amountflow[amount], ) for party_role in party_roles: insert_event_party_role( event_idevent_id, party_idparty_role[party_id], roleparty_role[role], ) # 投影更新可选见下文 refresh_projections_for_event(event_id) return event_id这段代码的核心是“一个事务”三个字。事件、资源流、主体角色必须要么全部成功要么全部不成功只要任何一张表写了一半整个模型的数据就会不一致。4.3 余额不是字段是查询结果事件流落库以后库存余额和应收余额都不再是单独的“余额表”字段而是通过事件资源流聚合出来的投影。伪代码如下def get_product_stock(product_id): cursor db.execute( SELECT SUM( CASE WHEN f.direction in THEN f.quantity ELSE -f.quantity END ) AS stock FROM event_resource_flows f JOIN events e ON e.id f.event_id WHERE f.resource_id ? AND e.status committed , (product_id,), ) return cursor.fetchone().stock or 0这种写法最大的优势是逻辑单一库存多少完全由事件流决定不会出现“事件还没写完余额先被改了”的情况。缺点是当事件量特别大时每次都全量聚合性能会差。解决办法是加投影表也就是库存快照表每天定时重算或者每次写事件后增量更新投影。投影表只是缓存不是事实源丢了可以重建。4.4 一致性问题事件先持久化投影后更新这里有一件反复纠结的事事件流和投影到底谁先写我的答案很明确事件是唯一事实源投影是派生物。任何更新流程都必须先把事件写进事务然后更新投影或者根本不更新投影让读取时实时计算。如果系统必须要实时库存我给的做法是在同一个数据库事务里先把事件表、资源流表、主体角色表三条记录写进去紧接着更新投影表的汇总计数。因为整体在一个事务里外部读投影时绝对看不到半个事件状态。投影更新失败整个事务回滚事件也不会落库。事件表保持干净投影永远能和事件对齐。有的团队喜欢引入独立的事件存储中间件我仔细评估过认为小团队没有必要。普通关系数据库的事务已经完全满足我们的事件和投影一致性需求。真正的业务复杂度不在于用什么存储而在于事件模型怎么设计。4.5 选型取舍普通关系数据库够用有人看完上面的代码会问这是不是事件溯源要不要换专门的 Event Store我的观点是不要把调子起太高。事件溯源本质上是一种建模思想核心是“事件记录业务事实状态由事件推导”跟具体存储引擎没强绑定。我们在普通关系数据库里建五张表用事务保证一致性已经拿到了事件溯源 80% 的好处。真正值得上专门事件存储的场景是面临跨服务多写、需要高并发事件回溯、或者要求存储层不可变审计链的时候。一个小进销存系统贸然引入额外组件只会让部署和排查变难得不偿失。5. 报表与对账用 REA 视图复原借贷数据5.1 业务层易懂不等于财务层能直接看REA 模型把业务讲得清楚但真到月底财务同事打开系统还是会问应收账款余额在哪儿销售收入在哪儿他们不关心发了多少货只关心科目余额。这时候你需要一个“投影层”把业务事件翻译成传统财务报表口径。我一开始也觉得奇怪本来就是为了绕开科目才建 REA怎么报表又绕回答科目了后来想明白了REA 是给业务系统用的科目是给财务报告用的。两者之间不是替代关系而是转换关系。业务系统负责把事件记准报表层负责把事件转换为财务视角。5.2 用 SQL 视图还原应收账款的余额实现上最偷懒也最有效的办法就是建一个 SQL 视图。下面的例子把发货事件记为应收增加收款事件记为应收减少退货事件再冲减应收。很粗糙但能看懂思路CREATE VIEW v_receivable_balance AS SELECT p.id AS party_id, p.name AS customer_name, SUM( CASE f.event_type WHEN shipment THEN f.amount WHEN payment THEN -f.amount WHEN sales_return THEN -f.amount ELSE 0 END ) AS receivable_balance FROM parties p JOIN event_party_roles r ON r.party_id p.id JOIN events e ON e.id r.event_id JOIN event_resource_flows f ON f.event_id e.id WHERE r.role customer GROUP BY p.id, p.name;这段 SQL 把 REA 的事件流挂到了科目口径上。好处是统一逻辑都放在视图层底层事件流完全不受报表调整影响。以后如果要出“主营业务收入报表”再造一个类似视图把 shipment 事件金额归集到收入科目即可。5.3 对账的两种模式做财务系统对账绕不开。我们落地了两种对账模式各有各的用处。第一种是余额对账。按客户分组算应收余额然后跟财务总账系统里的应收账款科目余额对比。月底跑一遍两边一致就说明事件流基本没问题。这种模式粗粒度适合发现大问题。第二种是流水对账。把每一笔收款事件跟对应的发货事件做明细匹配。比如客户支付了 10800 元系统要把这笔钱拆到“应收 10800”这条资源流并和历史发货单建立勾稽关系。流水对账能发现具体到单的问题比如某笔收款少冲了、某笔退货数据写错。实际体验里流水对账一旦跑通余额对账基本就是走个过场。5.4 用一个时间线案例复现完整业务流对账过程中最有用的工具是把事件按时间线展开。随便拿 6 月份这个客户做例子日期事件库存变化应收变化6月1日创建销售订单不变不变6月3日发货 100 件库存 -100应收 120006月8日退货 10 件库存 10应收 -12006月15日收款 10800 元不变应收 -10800银行存款 108006月30日月结库存减少 90 件应收余额 0看到这个表业务员、财务、程序员沟通起来异常顺畅。以前问“为什么余额不对”锅往往甩来甩去现在直接把事件时间线摆出来一眼就能看出哪个环节的数据漏录了。6. 实操中的常见误区与取舍6.1 别把订单、合同、报价单都建模成资源这是所有刚接触 REA 建模的人最容易犯的错。表面上看订单有编号、有金额、有状态好像跟资源很像。但 REA 里的资源必须具有可交换、可储存、可转移的特性。订单是承诺合同是约束报价单是意向它们都不能被“库存”或“耗用”。把它们当资源会污染资源表让余额查询出现各种没有意义的行。正确做法是把这些单据作为事件组或事件抬头单独建表通过事件编号挂接。它们自己有一套状态机但不参与资源量计算。6.2 主体关系别设计成“一个客户一张卡”建模初期我们给主体表只设计了名字和类型后面业务提出一个客户可能有多个联系人、多个收货地址、多个开票抬头如果地址信息直接塞进主体表就会被迫反复改主体表。后来我把联系人和地址拆成了主体附属信息主体表本身只保留身份和类型。事件主体角色表仍然只跟主体关联不跟联系人或地址关联。这样虽然多引入了两张小表但主体模型稳定很多后续加再多联系人都不会影响到事件网络。6.3 金额和数量别混在一个字段里这个看起来很基础但我们在需求阶段真的接到过“把数量和金额合并成一行”的诉求。要是一开始没有守住分开的原则后面做报表会痛苦到怀疑人生。数量用于库存和物流计算金额用于财务对账两者可以同时出现但必须分字段存储并且明确标注单价、含税金额、不含税金额。发货 100 件和金额 12000 元如果合并到一行再加备注所有聚合查询都做不了。还有一个容易忽略的点保存金额时要带上币种和汇率。我当时没管这个后来海外客户一出现只能补做一套换算逻辑费了挺大劲。6.4 REA 不替代账务系统而是与总账并行项目做了一阵子以后财务领导找过我一次问要不要直接用这套 REA 数据替换总账系统。我的建议是不要。REA 模型擅长描述业务事实但传统总账模型在记账规则、期末调账、结转损益、凭证审核这些方面已经积累了非常成熟的流程硬换成 REA 反而会让财务操作人员无所适从。正确的方式是让 REA 事件流成为业务系统的地基通过报表视图把结果同步给总账系统总账负责财务核算REA 负责业务追溯。两者各有分工中间用对账机制握手。这套并行架构让业务部门和财务部门都满意数据也一致。6.5 给团队协作一个小建议最后分享一个特别有用的团队管理经验给每个事件类型写一句话说明书。事件类型一多大家很容易凭感觉定义新事件比如把“出库”和“发货”当成两个事件。我们在项目里为每类事件建了一个文档写明触发条件、流向哪些资源、必须关联哪些主体、生成哪个报表口径。新人上手时看着这个文档做事件定义基本不会跑偏。最后说点实在的这个代号 rea 的项目最初也就是一个普普通通的进销存需求但用 REA 建模之后整个数据结构变得非常结实后面加新业务时不用再纠结改表结构。我个人最大的体会是建模的乐趣不在背概念而在把一个模糊的业务描述变成一张能讲清楚资源、事件和主体的关系网。如果你想在小项目里尝试 REA我建议先用最简的三张表跑通一件事再慢慢演进来不要一上来追求完美模型。踩过几次坑之后你会发现这张关系网真正值钱的地方是它把每个业务动作都变成了可追溯的事实而不是一笔难以回放的流水。