第一次被塞给我一个叫 rea 的需求时我一度以为是上游文案打错了字。后来才知道这不是单词拼错而是一套业务建模框架的缩写——REAResource-Event-Agent资源-事件-参与者。真正让我对它产生兴趣的是当时一个非常拧巴的处境销售要打通订单到回款的全链路财务坚持用科目和总账库存系统只认数量和仓库三套口径各说各话却没有一个能回答我们到底做过哪些事。先别急着把它想得太学术。REA 的核心思想一句话就能讲完业务系统不应该围绕账怎么记来建而应该围绕业务事实是什么来建。所谓业务事实就是谁在什么时间通过什么事件让什么资源发生流入或流出。听起来简单但把这一句话真正落到数据库里能省掉后来无数的对账和审计改造。这篇文章我打算从传统账本模型的问题讲起再到 REA 三要素的具体职责用一个模拟的电商订单系统把它走通然后把我自己在落地中踩过的坑和排查思路完整写出来最后聊聊它对事件溯源和领域驱动设计的意义。1. 从账本思维到REA 思维传统账本模型卡在哪里1.1 复式记账模型把业务压成了两根线绝大多数企业信息系统尤其是涉及财务的部分底子都是复式记账借、贷两个方向配上一张科目表。售出商品时财务写借应收账款、贷主营业务收入同时成本结转时再借主营业务成本、贷库存商品。这套模型运行了几百年稳定性无可挑剔但放到数字化系统里有一个致命问题它把复杂的业务事实压缩成了两根线。什么叫做压缩举例来说一笔销售订单里包含客户是谁、销售员是谁、哪个仓库配货、哪批商品、约定何时发货、是否开了发票、回款期限到几号。这些信息在记账凭证里最终只剩下借贷科目和金额其余全部塞进摘要这种自由文本里。等你需要回答上个月某区域仓库发给某客户的某类商品当时是谁审核的库存出库时你只能翻摘要、查订单表、对ERP日志靠人工拼凑。这不是执行力的问题而是模型本身没有为业务事实留下位置。科目表是面向报表设计的借贷分录是面向汇总设计的它们都不是面向事件设计的。所以每当业务方要求从订单一路追踪到回款、从入库一路追踪到结算时传统账本模型就会逼着你额外建一堆流水表日志表状态变更表来补账而这些表彼此之间又没有统一规则越补越乱。1.2 为什么需要一层独立的业务事实层我在某个跨部门项目里吃过一次大亏销售提成、采购付款、库存出库、财务应收四套系统各有各的明细表但是它们的更新时机不一样有的按天跑批有的实时写入导致同一天的业务在四张表里对不上。最后花了整整两周做数据核对才意识到问题的根源不是数据算错了而是我们从来没有建立过一份哪个动作在什么时间导致了什么资源变化的公共事实记录。REA 的价值就是强制你把这层业务事实层单独建出来。它的出发点和复式记账完全不同不先问这笔钱进哪个科目而是先问一项资源被谁、通过什么事件、流入了还是流出。资源可以是商品、现金、工时、服务事件可以是下单、发货、付款、收货、退货参与的人或组织就是参与者。任何一个业务流程拆到最后都是这三样东西在反复组合。这套思想最早出现在会计信息系统理论里上世纪八十年代就有人系统提出初衷是想让会计系统不仅能算账还能承载业务语义。后来大家发现它对订单、库存、供应链同样适用。因为只要涉及有东西移动了、有人参与、有责任需要追溯的场景REA 都能给出统一坐标。这层业务事实层一旦建好账怎么记、报表怎么做、状态怎么展示都可以在它之上派生再也不用每种需求各建一套表。1.3 REA 的建模目标描述业务如何发生而不是账怎么做我给团队讲 REA 时常用一句话概括账本是业务的影子REA 想抓的是业务本体。所谓业务本体就是那些已经真实发生、不可改变的动作。订单被创建是事件支付被登记是事件库存被扣减是事件而订单状态从待付款变成已付款这个结论不是事件它只是事件发生后算出来的结果。这条边界很关键。你仔细想几乎所有对账纠纷都来自状态覆盖订单状态字段被 update 成已发货之前是谁、在什么时候、做了什么操作导致这个变化一旦没有事件记录就死无对证。REA 要求你保留的恰恰就是这些随时可能被覆盖的事实。所以它的建模目标非常明确——把业务发生的过程完整留下来至于账怎么记、库存余量怎么算、报表怎么出全都排在事实之后。2. REA 三要素的职责划分与关联规则2.1 Resource 资源什么在被交换和被消耗在 REA 里Resource 指的是企业能够计划、交易、控制的有价值资产。常见的有商品、货币、应收票据、库存原料、可用的服务工时也包括无形的权益比如软件许可、知识产权份额。判断一样东西能不能建模为 Resource有一个很笨但很好用的标准它是否会通过某个事件从一方流向另一方或者被消耗掉举个例子咖啡豆是咖啡店的 Resource因为进货事件让咖啡豆流入销售咖啡的事件让咖啡豆流出并消耗。但天气不是 Resource除非你是在做气象数据交易平台把数据当商品卖。很多初学者喜欢把一切可量化的东西都建成资源最后连客户满意度都建了表这在模型上说不通——它不会随业务事件发生合法流入流出。Resource 建模时还要区分数量型和价值型。库存适合用数量和计量单位描述货币和账务适合用币种和金额描述。REA 并不要求把两者硬塞进同一个字段而是通过 flow 记录把资源流动的时间点和方向固定下来。你在设计表时Resource 本身只需要保存它的静态属性动态变化都交给 Event 和 flow 来承载这样资源表就很少被 update。2.2 Event 事件唯一真正发生的业务事实Event 是 REA 模型的核心也是和普通状态字段差别最大的地方。一个合格的事件必须满足三个条件在某个时间点真实发生至少引起一项资源的流入或流出有参与者的控制和参与。比如客户下了订单这是一个事件它导致库存可售数量发生变化参与者是客户和接受订单的客服。仓库完成配货也是一个事件它导致账面在库数量减少、待发货数量增加。连财务给供应商开出付款审批也可以是一个事件它代表了资金流出的承诺。反过来说客户满意度降低不是事件它没有资源在特定时点流动订单处于完成状态也不是事件它只是多个事件发生完之后的投影。每记录一个事件我们都会在心里做一次追问这件事能不能还原出谁、何时、做了什么、涉及哪项资源、带来多少变化能回答的才进事件表不能回答的先进候选区。这个筛选动作本身就能帮你过滤掉很多伪流水。2.3 Agent 参与者谁在推动和承担责任Agent 是事件的主体分为内部参与者和外部参与者。内部参与者通常是企业内部的员工、部门、角色比如配货员、仓库主管、复核员外部参与者是客户、供应商、承运商等。REA 的经典规则是每个事件至少关联一个内部 Agent 和一个外部 Agent这样既能回答谁负责了这件事也能回答这个动作对面是谁。这条规则在落地时经常被简化掉。很多系统只记录一个 user_id既说不清是客户操作的还是员工操作的也说不清连带的审核人是谁。等到出纠纷了审计问一句这批货出库由谁授权发现系统里只有系统自动任务记录没有任何人工责任节点那就非常被动。我在设计时会为事件预留两个角色维度internal_agent_id 和 external_agent_id哪怕某些事件外部参与者和内部参与者是同一个系统的虚拟账户。比如系统自动库存同步外部 Agent 可以标记为 SYSTEM_ACTOR这样语义上仍然保持完整。等以后接入自动化流程再把 SYSTEM_ACTOR 替换为对应的服务账号也不迟。2.4 三类关系存量-流量、因果和控制REA 的关系模型看起来复杂但归结起来也就三类。第一类是存量-流量关系Stock-Flow描述 Resource 和 Event 之间量的增减。库存和入库事件出库事件之间就是这种关系。存量本身不是独立存在的东西它是流量的累计结果。第二类是因果依存关系Causality描述 Event 之间的先后驱动。比如销售订单导致发货事件发货事件导致收款事件。发货不一定发生在订单之后就能代表因果真正的因果要求前者是后者的启动条件。有了这一层关系你才能顺着一条链追下去从最初的询价到最终的回款中间每一步都能串起来。第三类是控制关系Control连接 Agent 与 Event表示特定参与者驱动了特定事件。控制关系还包括职责分离比如建单的人和审核单的人不能是同一个角色——这恰恰是内部审计最喜欢查的环节。关系类型连接对象解决的核心问题典型例子存量-流量Resource ↔ Event资源从哪来、到哪去、剩多少入库事件增加库存销售事件减少库存因果依存Event ↔ Event一件事因何而起、会触发什么订单确认事件触发发货事件控制Agent ↔ Event谁批准、谁执行、谁能审计仓管员执行发货复核员审批出库三类关系分别回答了钱物怎么变为什么变谁让变这三个问题。把这三个问题答全了这个业务事实才算真正记录完整。3. 动手建模用一个模拟电商订单系统走通 REA 全流程3.1 建模对象与业务边界我拿一个虚构的小型电商系统来演示。场景不需要复杂但要覆盖到订单、库存、资金、佣金四条主要线索客户在前台下单之后平台要完成支付、配货、发货、确认收货可能还要处理退款后台要向供应商采购补货并且定期与供应商结算销售员根据销售额拿提成。放在传统系统里这就是销售系统、WMS、财务系统、薪酬系统四摊事。用 REA 建模时业务边界就是一句话记录所有改变企业资源归属的事实。客户下单、支付到账、商品出库、客户签收、退货入库、供应商发货、财务付款、佣金计提这些都包含在内。而纯粹的查看导出报表不算事件因为它们不引起资源变化。3.2 三要素识别清单拿到业务流程后我习惯先画一张三要素识别清单把每步动作的 Resource、Event、Agent 全部列出来而不是直接开始建表。这一步能避免漏掉关键事实。下表是简化后的清单业务步骤涉及资源对应事件内部参与者外部参与者客户提交订单商品可售数量订单创建客服/系统客户客户完成支付平台可动资金收款登记财务/系统客户仓库配货账面在库数量、可售数量配货完成配货员—仓库发货商品实物库存出库发货配货员承运商客户确认收货商品所有权收货确认客服客户客户申请退款商品可售数量、资金退款受理客服客户财务退回款项平台资金退款支付财务客户供应商发货补货商品在途库存采购收货采购员供应商财务向供应商付款平台资金付款结算财务供应商计提销售提成销售劳务、应付佣金佣金计提薪酬专员销售员注意我特意在表格里留了两处内部参与者为空的地方实际落地时不能留白。配货事件的外部参与者虽然没有客户但至少可以填系统内部定义的仓库流程账号。REA 要求每个事件都有内外参与者是为了让责任链条闭合不是为了制造死板的规则。3.3 事件之间的因果链仅有三要素还不够要把事件串成链。在这个电商系统里订单创建事件是整条链的起点它触发支付事件、配货事件、发货事件发货完成后才允许确认收货事件发生确认收货之后才形成真正可结算的收入事件。另一边采购收货事件触发付款结算事件销售员完成订单后触发佣金计提事件。这个链条直接来源于业务规则不允许先发货后收到订单不允许未收货就完成结算不允许没采购就凭空变出库存。把这些规则落到因果关系里比散落在状态机代码里更稳因为状态机只约束单张订单的状态流转而因果关系约束的是一个业务周期的完整闭环。3.4 从 REA 到物理表结构REA 落地到数据库并不复杂核心是四张表Resource、Agent、Event、ResourceFlow。ResourceFlow 是 Resource 与 Event 之间存量-流量关系的物理化一条事件至少对应一条流入或流出记录。CREATE TABLE resource ( id BIGINT PRIMARY KEY, resource_code VARCHAR(64) NOT NULL, resource_name VARCHAR(128) NOT NULL, resource_type VARCHAR(32) NOT NULL, -- commodity / money / labor unit VARCHAR(32), currency_code VARCHAR(8) ); CREATE TABLE agent ( id BIGINT PRIMARY KEY, agent_code VARCHAR(64) NOT NULL, agent_name VARCHAR(128) NOT NULL, agent_kind VARCHAR(32) NOT NULL -- internal / external / system ); CREATE TABLE business_event ( id BIGINT PRIMARY KEY, event_code VARCHAR(64) NOT NULL, event_type VARCHAR(64) NOT NULL, occurred_at TIMESTAMP NOT NULL, internal_agent_id BIGINT NOT NULL, external_agent_id BIGINT NOT NULL, ref_event_id BIGINT, description VARCHAR(512) ); CREATE TABLE resource_flow ( id BIGINT PRIMARY KEY, event_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, flow_direction VARCHAR(16) NOT NULL, -- IN / OUT quantity DECIMAL(18,4), amount_value DECIMAL(18,2), project_time TIMESTAMP NOT NULL );这张表看起来比常规的订单流水复杂但它换来的是极强的统一性。无论订单域、库存域、资金域所有人都在往同一张事件表里写所有资源变化都能通过 resource_flow 关联。金额和数量分开两个字段是为了兼容数量型资源和价值型资源两类场景比如购买劳务时数量是非标准化的金额才是核心。3.5 用 REA 推导库存、应收、应付REA 建好之后日常查询都是从事件流推导来的而不是去 update 一堆累计字段。比如查询某个 SKU 的当前库存只需要计算该资源所有 IN 流量的数量减去所有 OUT 流量的数量SELECT r.resource_code, SUM(CASE WHEN f.flow_direction IN THEN f.quantity ELSE 0 END) - SUM(CASE WHEN f.flow_direction OUT THEN f.quantity ELSE 0 END) AS stock_qty FROM resource r LEFT JOIN resource_flow f ON f.resource_id r.id WHERE r.resource_code SKU-1001 GROUP BY r.resource_code;同理某个客户的应收余额等于该客户相关的所有销售事件对应的 OUT 金额减去该客户所有收款事件对应的 IN 金额。应付供应商、提成待发也是同一套算法。这样算出来的数字天然具备可追溯性因为每一分余额变化都能反向找到对应事件。这也是我后来更愿意用 REA 方式替代余额字段的原因余额是结果事件是原因数据库里应该多存原因少存结果。4. 落地 REA 时的五个常见坑和完整排查链路4.1 坑一把状态当成事件丢了审计粒度最容易踩的坑就是嘴上说用事件实际建表还是给订单表加了一个 status 字段配货状态、发货状态都通过 update 这个字段来切换。代码里看起来逻辑简单但一旦出了问题你没法回答从已付款变成已发货是哪个环节哪个人触发的。排查链路是先看表里有没有一个会被反复覆盖的当前状态字段如果有再看它的变更历史是否完整记录。我的自查问题有三个这个状态最后一次变更的操作者是谁这状态在昨天中午是什么值同一个订单能找出多少次状态切换记录如果三个问题里有一个答不上来说明你的状态变更过程没有被建模为事件。正确做法是保留 business_event 表把配货完成发货确认作为独立事件写入同时允许通过事件表实时计算出最新状态。4.2 坑二Event 缺乏参与者责任链条断裂另一个高频问题是事件表里塞了一大堆自动任务生成的记录却没有记录到底由哪个人工角色控制。有的系统把所有动作都挂在 admin 系统账号下表面看有 user_id实际这个 user_id 永远是同一个等于没记。排查链路从审计需求出发挑一笔有争议的退款尝试回答谁受理、谁审批、谁复核、谁执行打款。只要有一环只能看到 SYSTEM 账号或无法解释就说明参与者建模不完整。修复时不要急着在每张业务表上加一堆审批字段而是回到 REA 的控制关系一个事件涉及一个内部参与者和一个外部参与者如果某个业务环节确实没有外部参与者就显式地定义 SYSTEM_ACTOR 并写明语义。关键是让每个事件的参与者字段具有可查询性而不是全空或者全写系统。4.3 坑三资源数量口径与金额口径分裂库存系统说件财务说元业务报表说箱。同一项资源在不同系统里用不同口径表达是所有对账问题里最隐蔽的坑。它不是运算错误而是资源建模时没有把数量型资源和价值型资源分开建模导致的。排查链路是找一条库存流水和一条财务流水看它们的 resource_id 是否指向同一个资源再看 quantity 和 amount_value 是否各自有明确单位。如果库存表只有数量、财务表只有金额两表没法关联就是这个问题。我的修复习惯是允许同一资源同时拥有数量型和价值型两种度量但必须显式声明。资源表的 unit 和 currency_code 字段要各归各的resource_flow 里 quantity 和 amount_value 可以同时存在但绝不能把一个箱数当作金额来求和。4.4 坑四事件链断裂追不了因果因果关系的缺失往往在体量小的时候看不出来。比如你要查这个客户退款事件最初对应的是哪张销售订单如果订单和退款之间没有 ref_event_id 关联你只能靠时间模糊匹配既慢又不准。排查链路也很简单任意挑一笔事件连续问这个事件是被哪个事件触发的它又触发了哪个事件每次问完如果都要靠人工找单号说明事件链没接上。我建议在 business_event 表里保留 ref_event_id 字段把直接的前置事件挂上去。如果涉及多个前置事件就再建一张 event_dependency 关系表。别试图把全链路塞进一个字段那只会重蹈状态字段的覆辙。真实场景里一个发货事件可以同时被订单事件和配货事件触发用一张独立关系表最干净。4.5 坑五为了灵活把所有东西都抽象成资源刚接触 REA 的人容易走另一个极端什么都建成 Resource连业务类型、区域、渠道都建成资源然后用一个通用 resource_type 在接口里反复判断。结果是查询语句里 90% 的 where 都在过滤 resource_type复杂度和性能双输。排查链路是看资源表的用途如果某个资源每次上线不是被 IN/OUT flow 引用而是被当维度标签过滤那它就只是属性不是资源。渠道不是资源它是事件的一个属性订单来源不是资源它是订单事件的描述字段。建模时坚持一个原则只有会参与资源流入/流出的价值对象才落地成 Resource其他一律作为事件的属性字段记录。适度留出扩展余地就够了不用为了追求理论纯净而把所有东西都抽象化。5. 进阶REA 对事件溯源、DDD 和系统重构的启示5.1 REA 与事件溯源的关系如果你熟悉事件溯源Event Sourcing会发现 REA 和它有不少家族相似性。事件溯源强调系统状态由事件日志推导状态表只是一个可重建的投影REA 同样要求事件作为唯一事实来源资源余额和状态都是从事件流推导出来的。差别在于关注点。事件溯源核心是解决状态存储和重建问题——事件就是存储介质和系统演进的骨架REA 核心是解决业务语义的完整性问题——它帮你想清楚什么事件值得记录、资源如何流、参与者是谁。落地时两者可以叠加用 REA 设计业务事件的本体结构用事件溯源机制来实现这些事件的持久化和投影。我先用 REA 梳理出订单域、库存域、资金域的事件类型再把这些事件写入 append-only 事件表下游通过投影构建各类视图整体思路非常顺。5.2 REA 与领域驱动设计的映射做领域驱动设计时最常见的困惑是聚合根怎么划、边界怎么定。REA 可以当做一个辅助探测器使用。一组事件如果有明确的因果依存关系往往适合放在同一个聚合或至少同一个限界上下文里。比如订单创建→发货→确认收货→收款这条事件链在 DDD 里通常会被建模为一个订单聚合的完整生命周期。而供应商采购收货→付款结算属于采购上下文虽然和销售上下文共享商品资源但两者的管理责任不同。REA 帮助你把哪些事件强绑定和哪些资源被哪些上下文引用画出来再来识别聚合边界就清晰得多。Resource 可以映射为 EntityEvent 映射为带时间戳的 Domain EventAgent 则可以对应 Actor 或用户上下文。5.3 什么样的系统值得引入 REA不是所有系统都需要 REA。如果一个系统只是管理型 CRUD比如后台维护商品分类、修改页面配置、记录静态文章那用传统结构化建模效率更高强行上 REA 只会增加复杂度。但如果系统具备以下特征中的三条REA 就非常值得考虑需要跨部门对账需要审计追溯和责任认定业务流程经常调整同一业务同时被销售、库存、财务多个系统消费你正在做领域驱动设计或事件溯源重构。我见过一个做供应链金融的模拟项目顶层用了 REA 理顺三方资金流底层用事件溯源支撑账单变化最后把原先三套对不上的子系统统一成一条事实链业务和研发沟通成本骤降。5.4 落地节奏不要一次性推倒重来我自己的经验是REA 落地切忌大爆炸式重构。比较稳妥的节奏是第一步选择一条核心业务流比如订单到回款手工梳理它的 Resource、Event、Agent 清单第二步在现有数据库之上创建 schema 视图用查询把现有表的数据映射到事件流模型先证明它能推导出你需要的报表第三步再逐步把写入逻辑切到新的事件表保留旧表一段时间做双写校验最后确认一致后才把旧的状态字段和累计字段退役。这样做的好处是风险可控每一步都有可验证的产物。REA 不是银弹但它能强制你完成一件非常重要的事把业务发生的真相从业务记账的结果中分离出来。只记结果不记事件系统永远是在给账本打工记下事件账本才真正变成业务的一部分。最后分享一个小技巧我每次给新项目做领域建模都会随身带一个三问模板——什么资源在流动什么事真的发生了谁在其中参与了控制面对任何新需求先回答这三个问题再谈表结构、字段和接口。这三问看着简单却往往能从源头上救回你后面两周的对账时间。
