1. 项目概述与核心思路拆解

1.1 这个项目到底在做什么

我最早接触"rea"这个词，是在一次内部技术交流会上。当时我们正在重构一套老旧的进销存系统，业务方抱怨最多的一句话是："报表出的数，跟业务实际发生的事，总对不上。"后来我才意识到，问题不在报表本身，而在底层的数据模型。传统模型是按"记账凭证"的结构去建库的，每一笔业务都预先塞进了借贷方的框子里，等你想从不同维度去分析这件事的时候，数据已经被"账务处理"这个过程扭曲过一次了。

"rea"的全称是 Resource-Event-Agent，翻译过来就是"资源-事件-主体"。它不是某个软件框架，也不是某种编程语言，而是一套非常底层的业务建模思想。核心逻辑很简单：任何一笔业务活动，都可以拆成三个基本元素——谁（Agent，主体）在什么时间做了什么事件（Event），这个事件影响了哪些资源（Resource）。这套思想最早在八十年代初被会计信息系统领域的学者提出来，原本是为了改进传统会计模型对业务语义的丢失问题，但放到今天的互联网系统、企业级应用、数据中台建设里，它的指导意义反而越来越大。

我之所以花篇幅去讲这套理论，是因为它真的能解决实际问题。当你的系统数据量到一定程度，或者业务复杂到需要跨部门、跨系统协作时，建表之前如果没有一套统一的业务语义标准，后面会出一堆"同名不同义"、"同义不同名"的数据冲突。REA模型提供的就是这套标准：它强迫你在建表之前先把业务理顺，搞清楚谁、做了什么事、动了哪些东西。可以说，REA模型不是教你写某一段代码，而是教你怎么把业务翻译成数据。

1.2 为什么复式记账模型不够用了

很多人一听到REA，第一反应是"这跟会计的借贷记账法有什么区别？"区别其实非常大。传统的复式记账法，本质上是为了"账目平衡"和"防舞弊"这两个目标服务的。它把每一笔业务都拆成"借"和"贷"两个方向，分别记在不同的账户里。这样的好处是能快速对账，但坏处也很明显：业务语义被割裂了。

举个例子，业务员下了一笔销售订单，仓库发了一批货，财务开了一张发票。在传统模型里，这三个动作会被拆成好几张凭证，分别记进应收账款、主营业务收入、库存商品、营业成本等账户里。等你想追溯"这一批货到底卖给了谁、当时的售价是多少、成本又是怎么结转的"时，就必须把这些凭证再拼回去。拼的过程，就是数据加工的过程，数据一旦经过加工，就难免会失真。

REA模型的做法完全反过来了。它不关心借贷平衡，它只关心"真实发生过什么"。还是那笔销售业务，在REA模型里会记成这样：销售员（Agent）执行了一次销售事件（Event），这个事件减少了一批库存商品（Resource）的存量，同时产生了一笔应收账款（Resource）的增量。库存减少和应收增加之间的因果关系，是模型天然自带的，不需要任何人为调整。这样的好处是，从业务发生到数据落库，语义保持不变，后续做数据分析、审计追溯，都可以直接捞原始数据，不用再经历一遍"还原凭证"的苦差事。

我在实际项目中最大的感受是：用传统模型设计数据库，你容易把注意力放在"科目怎么设置、凭证怎么生成"上；用REA模型设计数据库，你被迫把注意力放在"业务流程到底怎么走、每一步产生了什么影响"上。后者对业务的理解深度，远胜于前者。

2. 核心概念详解与建模方法论

2.1 Resource（资源）的定义与识别技巧

在REA模型里，资源这个概念比一般人想象的要宽。它不仅仅是库存商品、现金、固定资产这些有形的东西，也包括服务工时、知识产权、数据资产、客户关系这类无形资产。判断一个东西能不能当作资源，最简单的标准是三条：第一，它对组织有经济价值；第二，它能够被明确地识别和计量；第三，它能够在事件中被消耗、转化或者产生。

我在项目里识别资源时，经常用"存量-流量"的视角来辅助判断。凡是存在"结余"这个概念的，基本就是资源。库存商品有结余，现金有结余，应收账款有结余，员工剩余的年假天数也有结余。只要你在业务描述里听到"还有多少"这种说法，背后基本都对应着一个资源。反过来，如果你发现某个东西只有发生额，没有余额，那它大概率不是资源，而是事件。

这里有一个容易踩坑的点：系统里的"账户"并不等于资源。比如"管理费用"这个科目，在传统模型里是个账户，但在REA模型里它不是资源，因为管理费用本身不是被管理、被消耗的对象，它只是导致某个资源减少（比如现金流出）的事件描述。建模的时候如果分不清这两者，表结构就会做得不伦不类。

资源的属性设计也有讲究。除了名称、编码、规格这些基础字段之外，我建议一定要加上"资源状态"这个字段。比如一件商品，在库是"可售"，被订单锁定了是"预定"，出库了是"已发货"。有了状态字段，做库存可用量计算时会方便非常多。这个字段在传统模型里是没有的，但对实际操作的意义非常大。

2.2 Event（事件）的定义与捕捉粒度

事件是REA模型的灵魂，也是最难建模的部分。简单说，事件就是业务活动中真实发生的动作，它必须回答三个问题：发生了什么、发生在什么时候、发生在哪个环节。不管你是叫它"领料单"、"销售出库单"还是"采购入库单"，背后指向的都是事件。

确定事件的粒度，是最考验建模功力的环节。同样一笔销售业务，你可以拆成一个宽泛的"销售事件"，也可以拆成"创建订单事件"、"确认收款事件"、"仓库发货事件"三个细粒度事件。拆到什么程度合适？我的经验是六个字：能否独立归责。如果某个动作需要由不同的人来负责、或者可能在不同时间发生，那就必须拆成独立事件。反之，如果两个动作永远同时发生、且由同一个人负责，可以合并成一个事件。

举一个实际例子：在我们的进销存重构项目里，最初设计者把所有销售流程合并成一个"销售事件"，字段里既有订单号又有发货单号还有发票号。结果做权责分离审计的时候发现，一个人就能在系统里完成从下单到发货再到开票的全流程，合规性检查直接不通过。后来拆成了三个独立事件，每个事件绑定不同的主体权限，问题才解决。这就是事件粒度没把握好带来的真实教训。

事件的时间属性也值得单独提一下。传统模型里，业务事件往往跟着"单据日期"走，也就是以录入系统的日期为准。但REA模型强调用"业务发生时间"而非"记录时间"。这两个时间如果不加区分，后面做业务流程时效分析的时候，数据会混乱得让人抓狂。我一般会在这两个字段上都保留，一个叫"发生时间"，一个叫"入账时间"，各用各的，互不干扰。

2.3 Agent（主体）的分类与权限设计

第三个元素Agent，指的是参与事件的主体。主体分两类：一类是组织内部的主体，比如某个部门的员工、某个角色；另一类是组织外部的主体，比如客户、供应商、承运商。区分内外主体的意义在于，内部主体的数据一定要跟权限体系关联，外部主体的数据更多跟信用体系、对账体系关联。

从建模的角度看，主体这个概念的边界比想象中更复杂。我第一次做REA建模的时候就遇到过这个困惑：仓库管理员和仓库本身，谁是主体？答案要看你在哪个事件里看。在"入库验收"这个事件里，仓库管理员是执行主体；在"库存盘点"这个事件里，仓库是整个事件的客体对象之一，更准确的定位是"被管理的资源"或者"归属单元"。这里没有绝对正确的答案，关键是在同一个模型里保持一致，不要在A事件里把仓库当主体，在B事件里又当资源，那就乱了。

主体的建模还有一个容易被忽略的细节：岗位和人员要分开。系统里的权限绑定应该绑定到岗位（角色），而不是绑定到具体的人。原因很简单，人员会流动，岗位是稳定的。用REA的术语来说，就是让"Agent"绑定到稳定的职位，而不是流动的个体。我在实际项目中处理过一个很头疼的场景：某核心岗位人员离职后，新员工接手系统权限，但因为旧模型里权限直接挂在具体人头下，交接时遗漏了一个隐藏权限入口，导致很久以后才发现离职员工的账号还能访问部分敏感数据。后来重构时我们做了岗位和人员的彻底分离，这件事才算彻底解决。

2.4 三元组之间的关系到底怎么连

REA模型的三个元素不是孤立存在的，它们之间有标准的关系类型。最核心的是事件跟资源之间的"库存流量关系"（Stockflow），它描述的是事件对资源的影响，是增加、减少还是转移。其次是事件跟主体之间的"执行关系"（Execution），它描述的是谁发起了事件、谁是事件的对象。另外还有资源跟主体之间的"保管关系"（Custody），描述的是某个主体对某类资源的控制权，比如仓库管理员负责保管库存商品。

这三个关系的落地方式，其实就是数据库里的外键关系。资源表、事件表、主体表，两两之间建立关联。实际操作中，我建议不要用"多对多"的关系直接连，而是设计成关联表，中间带上时间戳和业务描述字段。举个例子，"销售员A在3月1日向客户B销售了10件商品C"，如果只是简单地把A、B、C三个ID塞进一张关联表，后续各种查询都会很难写。但如果你把"销售事件"本身建表，事件表里挂销售员ID（执行主体）、客户ID（对象主体），另外建一张"事件-资源明细表"挂商品C的ID和数量，整个模型就非常灵活了。

关系建模时有一个很实用的检查方法：把模型画出来后，找一笔真实业务，沿着一笔流水从头走到尾。如果每一步都能清楚地回答"谁做的、做了什么动作、影响了什么资源"，这个模型基本就是合格的。如果中间有任何一步需要靠想象去补逻辑，那这块关系一定有问题，要回去重新理。

3. 实操过程：从业务需求到REA数据模型

3.1 事件穷举与流程梳理

理论说再多，不如动手做一遍。我拿一个典型的"客户下单到回款"全流程来演示，怎么把真实业务翻译成REA模型。

第一步，先把业务流程图摊开。从客户创建订单开始，到我们发货、客户收货、开票、回款，每个环节都列出来。这个阶段不要急着建表，只需要把"动作"写下来，写清楚每个动作的执行者是谁。大致可以得到这样一组动作：客户下单、销售审核订单、仓库拣货、仓库发货、客户确认收货、财务开票、客户支付、财务核销。这些动作，每一个都是候选事件。

第二步，对候选事件做合并和拆分。比如"仓库拣货"和"仓库发货"，在真实业务里可能是同一个人同一次操作，可以合并成一个"出库发货"事件。而"客户下单"这个动作，如果你的系统里既有线上自助下单、又有销售代下单，建议还是合并成一个"订单创建"事件，用订单来源字段去区分，而不是拆成两个事件。判断标准还是那句话：能否独立归责、是否可能独立发生。

第三步，给每个事件补充属性。除了事件ID、事件编码、发生时间、入账时间这些通用字段之外，一定要放一个"事件摘要"或者"业务备注"字段。文本型字段容易被人忽略，但在后期排查数据和做审计还原的时候，这个字段的价值比很多结构化字段都大。我用过的很多系统里，事件表里最后最有用的就是当初觉得"没什么用"的摘要字段。

3.2 资源识别与存量流量映射

事件梳理完之后，第二步是识别每个事件影响的资源。我的做法是，给每一个事件，单独画出"影响前"和"影响后"两张资源状态图。以"出库发货"这个事件为例，影响前是库存商品里有一批在库可用量的货；影响后是在库可用量减少、同时客户那侧多了一笔"在途应收"的权益。这样一画，资源的变化脉络就非常清晰了。

有一点要特别注意：一个事件可以影响多个资源，一个资源也可能被多个事件影响。比如"销售出库"这个事件，同时减少了"库存商品"资源、增加了"应收账款"资源，还可能产生"销售成本"的变化。反过来，"库存商品"这个资源，既可能被"采购入库"事件增加，也可能被"销售出库"、"盘点调整"、"报废处理"等事件减少。这种多对多的关系，就是前面说的需要建"事件-资源明细表"的场景。

每个资源在事件发生后的变化量，就是"流量"。流量的正负方向要和事件绑定：增加类是正流量，消耗类是负流量，转移类则是双边变化。把这个逻辑落到数据库，就是明细表里除了外键之外，要有一个"正负标识"或者"数量带符号"的设计。我见过一些项目在明细表里用"in/out"字符串来标识方向，虽然也能用，但查询时写条件很别扭，不如直接用正负数来得痛快。

3.3 主体识别与权限矩阵

第三步是主体识别。对前面穷举出来的每个事件，都要回答两个问题：谁负责发起这个事件？谁是这个事件的对象？主语的答案是内部主体，宾语答案则是外部主体或内部其他角色。

以"订单创建"事件为例，发起主体可能是客户（外部），也可能是客服代录（内部）。以"出库发货"事件为例，发起主体是仓库操作员（内部），对象主体是承运商和收货客户（外部）。把这些主体的角色和类别列清楚了，再跟权限体系做映射。每个事件天然对应一组操作权限：谁能新增、谁能修改、谁能作废、谁能查看。这个矩阵画出来，权限设计基本就是填表的事了。

这里有个很实用的做法：把主体识别结果作为系统需求文档的一部分，直接给开发人员参考。传统需求文档里对权限的描述往往很模糊，比如"要有对订单的完整操作权限"，这种描述交给开发，开发的实现方式五花八门。但如果需求文档里有"订单创建事件"的"发起主体"是哪些角色、"审批主体"是哪些角色，开发就知道要去建角色表、加数据权限隔离了。

3.4 建表结构与关系落地的具体方案

概念设计完成后，就是建表落地。以我们实际项目为例，核心表结构大致如下：

-- 主体表（Agent） CREATE TABLE agent ( agent_id BIGINT PRIMARY KEY, agent_code VARCHAR(50) UNIQUE, agent_name VARCHAR(100), agent_type TINYINT, -- 1=内部员工, 2=外部客户, 3=供应商 role_id BIGINT, department_id BIGINT, status TINYINT, created_at DATETIME ); -- 资源表（Resource） CREATE TABLE resource ( resource_id BIGINT PRIMARY KEY, resource_code VARCHAR(50) UNIQUE, resource_name VARCHAR(100), resource_type TINYINT, -- 1=库存商品, 2=资金, 3=应收权益 unit VARCHAR(20), current_qty DECIMAL(18,4), status TINYINT, created_at DATETIME ); -- 事件表（Event） CREATE TABLE event ( event_id BIGINT PRIMARY KEY, event_code VARCHAR(50) UNIQUE, event_type VARCHAR(50), -- 订单创建, 销售出库, 收款等 happened_at DATETIME, recorded_at DATETIME, initiator_agent_id BIGINT, -- 发起主体 object_agent_id BIGINT, -- 对象主体 summary VARCHAR(500), status TINYINT ); -- 事件资源明细表（Stockflow） CREATE TABLE event_resource_flow ( flow_id BIGINT PRIMARY KEY, event_id BIGINT, resource_id BIGINT, quantity DECIMAL(18,4), -- 正数=增加，负数=减少 unit_price DECIMAL(18,4), amount DECIMAL(18,4) );

这里要解释几个设计意图。第一，事件表和明细表分开，是为了支持"一个事件影响多个资源"的二维结构。第二，明细表里放数量、单价、金额三个字段，是为了兼顾三种分析口径：数量角度、价格角度、金额角度。传统模型里这三个口径经常被人为割裂，而在REA模型中它们天然在一条记录里。第三，事件表保留了"发生时间"和"记录时间"两个字段，这是我在踩过无数坑之后坚持保留下来的设计。

3.5 关键检查：用一笔真实业务走查模型

模型建完之后，千万不要急着写代码，先做一次"业务走查"。选一笔真实、完整的业务流，从第一个事件开始，沿着一系列事件的链路走一遍。以"卖出一台设备"为例：

客户A创建了订单（事件1），订单事件关联的资源是"在售设备"从可用变为锁定（资源变化），发起主体是客户A，对象主体是销售部。接着仓库执行出库发货（事件2），"在售设备"资源减少，同时"发出商品"资源增加（假设此时货权还没转移）。客户确认收货后，财务确认应收账款（事件3），"发出商品"资源减少，"应收账款"资源增加。最后客户付款，财务核销（事件4），"应收账款"资源减少，"银行存款"资源增加。

这条链路走下来，每一笔事件都能清楚地对应到资源的增增减减，模型就是自洽的。如果走到某一步发现对不上，比如"发出的货还没到客户手里，账上就开始提应收账款了"，那就说明事件的时间边界定义有问题，要回去调整。

我在实际项目中，每建完一个子系统模型，都会强制要求产品经理和核心开发一起做一次这样的业务走查。整个过程往往能暴露出大量业务流程本身的问题，这些问题的价值远高于模型层面的问题。

4. 常见问题与排查技巧实录

4.1 事件粒度选择困难症

我见过最多的问题，就是团队在"事件到底拆多细"这个问题上争论不休。销售部觉得一个订单就是一个事件，仓库觉得一次拣货就是一次事件，财务觉得一次收款才值得记一次事件。吵到最后，方案要么太粗，要么太碎。

这里我给一个可量化的判断标准：如果合并两个事件，会丢status信息，就必须拆开。什么意思？就是说，如果两个动作之间不存在"待处理"、"处理中"、"已完成"这些中间状态，说明它们没有独立跟踪的必要。反过来，只要线上系统里需要有某个中间状态展示给用户或者内部管理使用，就绝对不能合并。

另一个辅助判断的标准是追溯成本。如果合并事件会导致审计时无法判断某一特定时间点的责任归属，就必须拆。我就遇到过一个项目，把"发货"和"出库"合并成了一个事件，结果货在运输途中被调包了，系统里根本查不出来这批货到底是哪天、经谁之手出库的，最后只能人工翻纸质单据，极其痛苦。

4.2 多资源事件的拆分处理技巧

一笔销售，既影响库存，又影响应收账款，还影响税费——这种多资源事件怎么存？很多人第一次接触REA模型时，会试图把所有的资源变化字段都塞进事件表里，比如建一个"销售事件表"，里面既有商品字段、又有金额字段、还有税额字段。这样做的后果是，这张表的字段会无穷膨胀，而且一旦业务扩展出新的资源类型，又要加字段。

正确的做法是坚持"事件表和明细表分离"。事件表只记录这个事件本身的公共属性，比如发生时间、主体、摘要；明细表记录具体每个资源的变化情况，一行一资源。用之前给的那套表结构，这笔销售事件就有多条明细记录：一条是库存商品减少、一条是应收账款增加、一条是应交税费增加。查询的时候用事件ID关联明细表，怎么查都不乱。

这样设计还有一个额外的好处：可以非常方便地算每一类资源的周转情况。比如你想统计"本月所有减少库存的事件总共有多少"，直接对明细表按资源ID过滤加聚合，一行SQL就出来了。在传统模型里，这种查询要绕过好几层凭证和分录表，复杂程度不是一个量级的。

4.3 现有会计科目体系如何与REA共处

我承认，刚才说了半天REA模型的好处，但你在实际企业里，大概率还得跟现有的会计系统和平共处。财务部门要出报表，要满足外部审计的要求，这些依赖的是标准的科目体系，不会因为你说REA更合理就改变。

我的建议是：不要试图用REA模型去取代会计系统，而是让两套体系并行，各司其职。REA模型负责记录真实的业务事件全貌，作为业务中台的数据底座；会计系统负责把业务事件翻译成标准凭证，专门服务财务报告需求。关键在于，翻译过程要自动完成，根据事件类型和资源变化自动生成对应分录，而不是靠人工二次录入。

这样做的好处是，业务数据的完整性和准确性由REA模型保证，财务数据的合规性由会计系统保证。两边虽然语义不同，但底层数据同源，不存在对不上的问题。我们项目里给这套机制还加了一个"对账辅助表"，定期把REA模型里的"应收账款"余额和会计系统里的"应收账款"科目余额做对比，一旦有差异就触发告警，由财务人员介入排查。

4.4 过度建模与性能问题的平衡卡点

REA模型在性能上有一个天然的压力点：事件量会非常大。因为每个真实发生的业务动作都要记一条事件记录，加明细记录，量级比传统凭证系统大好几倍。有人一看这个数据量就慌了，考虑各种奇技淫巧来"优化"，比如把明细写进宽松字段、把多个事件合并存储，结果优化完业务语义又丢了。

我的经验是分两步走。第一步是用合适的存储手段抵抗数据量，例如按时间维度做分区、把历史数据归档到冷存储，这些手段很成熟，不破坏建模逻辑。第二步是合理使用"资源当前值冗余"。注意，这里说的是"冗余当前值"，不是"冗余过程明细"。比如资源表里的current_qty字段，就是冗余了当前库存的汇总值，不用每次实时聚合明细表才能看到现存量。但所有的明细记录依然完整保留，这样既满足了查询性能和业务查询需求，又不丢失审计追踪能力。简单说，就是查询走冗余，原数据永远留着。

这个方法是我在实际项目里反复验证过的最佳平衡方案：设计上保持理论的严谨，工程上照顾运行的性能。

5. REA模型的扩展应用与落地体会

5.1 从单业务到跨系统的扩展实践

当我把REA模型在单个子系统中跑通之后，发现它更大的威力在于跨系统场景。我们在一次B2B平台重构中，把多个业务方系统的数据统一按REA语义做了梳理。每个业务方各自的系统技术栈完全不同，有的用旧版数据库，有的用的非关系型存储，但是只要大家都按"谁、做了什么事件、影响了什么资源"来描述业务语义，跨系统的数据对齐就变得异常简单。

在跨系统数据交换的场景里，REA模型提供的其实是一套通用API接口契约。比如要对接供应商的发货系统，我们约定只要对方提供推送数据格式——某个供应商（Agent）在某时执行了出库发货（Event），出库了哪些商品（Resource）多少数量，我们就能把数据无缝接入到自己的库存体系里。没有人需要去理解对方系统的底层表结构，大家都对齐到REA的标准名词上。

这种做法的价值在传统模型下很难体会到。传统系统对接，经常是"我们把表结构发给你们，你们自己读"或者"我们有个接口清单，你们自己调"。接口项之间业务语义靠人的脑补。而REA模型把每一个接口动作都定义成主语、谓语、宾语，语义清清楚楚，对接效率至少快一倍。

5.2 在数据中台建设中的落地经验

做数据中台的人，最头疼的问题之一就是"怎么定义指标"。同一个"销售额"，市场部一个口径、销售部一个口径、财务部一个口径，三个数永远对不上。我在一个数据中台项目里，用REA模型做了一次大胆的尝试：所有指标必须先落到REA的事件和资源上。

比如"销售额"这个指标，我要求必须先说明它是哪个事件产生的资源增量。如果定义成"订单创建事件发生时，按订单明细计算的对客户的应收金额"，那这个指标的所有计算逻辑就是确定的。如果另一个人说"销售额是实际回款的金额"，那这个指标背后对应的是"收款事件"+"银行存款资源增加量"，这不是算错了，而是定义成了另一个指标。指标口径冲突的本质，是事件边界不清晰。REA模型直接把这个边界问题显性化了。

实施过程中我还发现，REA模型特别适合构建"自助取数"能力。业务人员只要理解了资源、事件、主体这三个核心概念的前置培训，就能自己组合查询条件。以前提需求到数据团队排队取数，动辄等一周，后来业务同事自己基于REA口径做取数，效率大幅提升。这是我在落地中感受最明显的一个增量价值。

5.3 个人实操建议与长期维护心得

最后聊点个人经验。如果你的团队准备从传统模型往REA模型转，我建议不要搞"一步到位"的大重构。更稳妥的做法是，挑选一个新启动的子项目或模块作为试点，总结一套适合自己团队的建模规范，再逐步推进。一上来就想把核心系统按REA全部重写，大概率会因为历史包袱和业务阻力半途而废。

建模规范这一点值得多说几句。我踩过的坑是，团队里每个人对"事件"的理解不完全一样，有人把"审核通过"也算事件，有人觉得只有产生资源变化的才算事件。后来我们内部定了一条硬规矩：不导致任何资源变化的动作不算事件，充其量算状态变更。这条规矩极大减少了模型里的噪音数据。如果你想采用一个划定标准，这条可以作为参考。

还有一个长期维护的坑：字段命名和术语表的维护必须跟上。REA模型强调语义统一，但如果你每次建新表都发明一套新的命名规则，语义统一就无从谈起。我建议在项目里固定一份术语表，明确每个概念对应的英文标识、业务含义、允许的特殊情况。每张新表上线之前先检查字段命名是否符合术语表，不符合的一律打回。这套流程看着有点笨重，但在多团队协作的场景下，坚持三个月就能看到明显效果。

结合我个人这些年的体会，REA模型不是一套死板的"标准答案"，更像是一副可以灵活运用的思维框架。它真正改变的是你面对业务时的思考方式：从"这个功能要建几张表"变成"这件事涉及谁、做了什么、影响了什么"；从"这个报表的数据从哪来"变成"这个指标对应的是哪个事件的什么资源变化"。一旦习惯了这种思考方式，再回头看那些为了迁就系统而造出的复杂业务逻辑，你会有种豁然开朗的感觉。如果你也在做系统重构或者新项目的数据模型设计，不妨先用几天时间，拿一笔核心业务走一遍REA的建模流程，推演一下这个业务的全生命周期，可能会得到一些不同于以往的认识。