企业官网建设流程全解析

REA这三个字母，放在一堆缩写满天飞的技术资料里毫不起眼，但凡是搞过企业信息系统、财务系统、供应链系统或者所谓“中台”项目的人，多多少少会被它卡过一下。我第一次接触REA，是在做一个想覆盖“采购到销售全链路”的库存系统改造，当时被十几个业务模块之间乱成麻的关系折腾到怀疑人生，后来认真把REA捡起来复盘才发现，很多根子上的问题根本不是前端交互或者接口性能，而是建模这一层就歪了。

REA全称是Resource-Event-Agent，翻译过来就是“资源-事件-施动者”。它不是某个开源框架，也不是某种具体技术组件，而是一套用于业务领域建模的分析范式。简单说，它告诉我们一件事：在真实业务里，什么东西值得进入系统、业务活动该以什么为粒度被记录下来、人和组织之间是怎么发生权责关系的。这套思路最早是会计信息系统领域的研究者提出来的，初衷是用来替代传统复式记账法在信息系统里的建模窘境，但后来逐步被用在了ERP、订单管理、库存核算、事件溯源架构等更广泛的场景中。这篇文章就从一个实践者的角度，把REA从“听说过”拆到“能上手”，说说它到底怎么用，坑在哪里，以及一套可以直接落到表和接口上的建模流程。

适合认真读完的人，包括：被业务需求反复推倒重来的后端开发者，做中台或数据架构的设计师，天天跟单据流转较劲的产品经理，以及想给自己攒一套“没那么容易烂”的领域模型的技术负责人。

1. 先想明白一件事：业务建模为什么容易烂

1.1 账户驱动的老思路，坑在“科目先行”

传统财务系统里，建模起点是会计科目。拿到一个需求，很多人习惯先问“这笔钱记到哪个科目”，于是整個系统里全是凭证、科目余额、借贷分录。这套东西在财务核算这个专业件事上确实成熟，但一旦想把业务流程本身管起来，它就有两个很难受的地方。

第一，科目是为报表服务的，不是为业务服务的。一个订单从下达到回款，可能拆成预收款、收入确认、应收、成本结转一大堆科目。每一个科目背后都带着复杂的记账规则，业务人员理解不了，技术人员更不敢乱动。第二，账户驱动模型天然是“事后记录”。它记录的是业务发生之后的价值变动，但业务过程中的状态、承诺、责任、时间点统统被压扁了。你想回答“这批货现在到底在哪”、 “这个承诺什么时候到期”，靠科目余额是看不出来的。

REA从一开始就不按科目走。它先回答“发生了什么业务事件”，再回答“这个事件涉及哪些资源、有哪些人参与”。账怎么做，那是后话，可以围着模型推导出来，而不是反过来逼着所有业务细节去适应记账规则。

1.2 REA的核心主张：把“事件”当主角

传统建模习惯把“实体”当主角，比如客户表、商品表、订单表，一张表代表一个静态对象。时间一长，表和表之间全是外键关联，状态字段越加越多，每个状态都靠程序逻辑维护，业务规则散落在各个Service里。REA的反直觉之处在于：它不把客户和商品当成最重要的静态实体，而是把“发生了什么事件”当成最核心的锚点。

打个生活化的比方。你周末在家做蛋糕，面粉、鸡蛋、烤箱是资源，你本人是施动者，“搅拌面糊”“烘烤”是事件。面粉不会自己做蛋糕，也不会自己变成蛋糕，它是在某个时间点，由某人执行某个动作后才变成了新资源。REA要求你把“搅拌”“烘烤”这些动作显式建模，而不是只在系统里记一个“库存面粉少了两百克，库存蛋糕多了一个”。

为什么这么强调事件？因为真实业务里，所有资源变动的背后都有一个时间点、一个责任人、一个业务契约。把事件作为一等公民保存下来，这个系统就有了“过程记忆”。往后无论是追溯历史、做审计、算提成还是做数仓，数据底座都是齐的。这跟今天微服务架构里经常提到的“事件溯源”思路是一脉相承的，而REA可以看作是事件溯源在业务建模层面的老前辈。

2. 三要素拆解：Resource、Event、Agent应该怎么抓

2.1 Resource：是“存量”和“流量”的边界

REA里的Resource，指的是经济资源，通俗讲就是“有价值、可以被交换或消耗的东西”。它既包括有形资产（商品、现金、原材料、厂房），也包括无形资产（服务工时、知识产权、数据资产）。识别一个东西算不算Resource，有个很简单的判断标准：它是不是“被一个事件带进来，然后被另一个事件带出去”。

于是资源分成了两个视角。存量（Stock）是某个时点系统里实际拥有的资源量，比如仓库里现在的库存数、银行账户里的余额。流量（Flow）则是从一段时间的维度看，进了多少、出了多少，比如一个月的入库总量、销售出货总量。REA里有个很关键的要求：存量必须与流量保持一致。每次事件发生，对应的资源流量变动，最终产生的存量变化必须能对上。这一点跟库存账、现金流对账的本质是一样的，但在REA里它不是靠事后核算，而是模型上天然强制出来的。

做建模的时候，常见错误是把“单据”当成Resource。订单、合同、发票这些是记录业务事件的载体，不是资源本身。资源一定是可以被某种事件消耗或产出的东西，而单据不会因为采购事件而减少，它只是事件发生后的“凭据”。如果你把一个系统里所有主数据表都标成Resource，REA模型就退化成ER图了，丧失了它最值钱的分析力。

2.2 Event：识别“原子业务动作”的粒度

事件（Event）是REA模型的心脏，识别得好不好，直接决定模型盘点生命周期内需要哪些字段。

什么样的事情才配叫Event？要满足三点：发生在某个时间点；有明确的施动者；能导致至少一个资源的流入或流出。比如“客户提交订单”不算事件，因为此时没有资源流动，只是表达了一个意图。“仓库发货”算事件，因为它导致了“库存商品”流出，也意味着要向客户履约。订单可以是事件的前置条件，但它本身更接近“契约”，不是资源流动本身。

这里要给新手一个实用建议：先别急着把所有页面操作都建模成Event。越贴近真实世界资源变化的那一步，越适合作为Event。电商的“用户点击了加入购物车”是操作，“完成支付”才是事件。医院系统的“医生录入了处方”是操作，“药品已发放给患者”才是事件。

事件还要区分“经济事件”和“契约事件”。经济事件直接导致资源流入流出，契约事件则表达承诺或义务的建立，比如“签订合同”、“下达采购订单”。REA里有一个“豁免机制”的细节：当经济事件已经发生时，对应契约的执行义务应该自动满足或清零，而不是靠另一个定时任务去核对。很多系统里“履约率算不对”的问题，根源就是这个豁免逻辑没建模清楚。

2.3 Agent：找“谁”和“对谁”，以及权责链条

Agent（施动者）是事件的执行者或接收者，可以是个人、部门、外部客户、供应商。注意，不是说所有参与者都要一张大宽表，而是要区分两种角色：内部Agent（比如采购员、仓管员）和外部Agent（客户、供应商）。在REA建模里，事件的内部施动者一般是“责任归属方”，外部施动者则是“交易对手方”。

一个事件至少要有一个内部施动者，这是“可审计性”的底线。很多系统做了一段时间后查无实据：库存少了，但不知道是哪个仓管员在哪天做的出库；订单退款了，却不知道是哪个客服在什么条件下操作的。REA把这个约束放在模型层面，等于接口强制要求事件必须带操作人，从源头避免了“孤儿操作”的产生。

Agent之间的权责关系也值得单独强调。客户A的账户不能替客户B下单，供应商C的入库单不能被供应商D的人签收。这些规则如果散落在代码里，每次权限变更都要改代码；如果建模时就把Agent和事件、资源之间的授权链画清楚，很多权限问题就变成了结构约束的问题，安全性和可解释性都会好很多。

3. 实操路径：从业务流程到一份能落地的REA模型

3.1 先圈业务边界，画一张“事件链”草图

做REA建模，第一件事不是画ER图，而是把业务流程从“起点”到“终点”的表达干完。随便找一个真实典型场景：某小型电商公司，从“供应商采购补货”到“客户下单付款再到物流发货”。我们要把这条链上所有“资源发生物理或法律转移”的时刻列出来。

按顺序一列，差不多是这样：

• 采购员向某供应商下达采购订单（契约事件）
• 供应商发货、我方仓库验收（经济事件，库存商品流入）
• 财务按入库单支付采购款项（经济事件，现金流出）
• 客户在商城提交订单并完成付款（支付这个动作在这里可以视为经济事件，资金流入）
• 运营或仓库按订单拣货并包装（经济事件，库存商品流出）
• 物流公司揽收包裹，商品离开仓库（资源从“自有库存”流入“在途物流受托商品”这个资源，如果精细建模的话）

这张草图不需要很完美，但它能帮你找到所有Event的候选。注意，我在这个草图里把“客户提交订单”和“客户完成付款”做了区分，因为下单只是一项承诺，资金真正流入发生在支付那一刻。区分清楚之后，后续出库判断能不能发、财务何时确认收入，都具备了建模基础。

3.2 再给事件标上“血缘”：Stock-Flow关系

模型里，事件不直接跟另一个事件发生关系，而是通过“资源”间接产生联系。这个联系叫Stock-Flow关系，意思是“某个事件让某种资源流入或流出某个存量池”。

继续用电商的例子，“供应商发货”事件会让“库存商品”这口存量池的水位上升，“拣货出库”事件会让同一口池子的水位下降。一进一出，共享同一个Resource，才构成了真正意义上的“库存账”。如果两个事件各自关联不同的资源表，比如一个关联“入库单”一个关联“出库单”，那不是REA建模，只是普通的表关联。

画图的时候，Stock-Flow关系就是“事件”和“资源”之间的有向边。这种图建议用手涂或者画板工具先做，不用一上来就整正规建模软件。我实测下来，一张白纸画事件（圆圈）、资源（矩形）、Agent（三角形）之间怎么连，比在电脑上拖半天框效率高得多。

3.3 把模型映射到表结构，一次到位

有了事件链和Stock-Flow关系，表结构其实是自动长出来的。最基本的落库规则是：

• Resource对数一