规则是流动的。 互联网的美妙，在于可以重构规则，从而革新现有的一切。
概述
中大型业务系统中，往往多种业务相互交叉，错综复杂，使得系统变得难以理解。一般的方法是，通过阅读工程代码来理解系统。但这种方法是有局限性的。因为工程代码，往往是系统设计实现与业务的混合体，并不完全一致地表达着业务本身：
- 由于当时的技术和系统架构的限制，往往实现的并不是最优的业务视角，而是折衷过的；
- 部分代码写得比较蹩脚，表达不准确，甚至有 BUG ，反而妨碍真正理解业务本身。
要真正理解业务，需要从业务本身上去理解，严格区分出“业务规则”与“系统设计与实现”这两个不同的层面。工程代码，可以作为重要的参考。
三要素
数据模型
数据模型指的是，需要哪些数据项，数据项之间的关联，如何有序地组织这些数据项。数据模型是软件整体设计的导航图。确定良好的数据模型，设计就成功了一大半。
比如交易的基本数据模型如下。通过这个模型，可以全局式地概览交易所涉及到的各种基本数据、各个基础模块，有一个整体而基本的把握。
针对具体业务，则可更容易地理解和分析。具体业务的数据模型，通常是基础数据模型再加上一些扩展性的数据集。
如何提炼数据模型呢 ？
可以从工程代码里的各种 DO，DTO ，服务接口返回的数据对象入手。推敲每个字段的含义，将其进行归类。这时候，采用的是有选择性地阅读，阅读代码呈现的关键对象，而不是在荆棘丛生的代码中穿梭，弄的遍体鳞伤。
规则
规则指的是，数据项及流程要满足什么约束 ？为了什么目标而服务 ？
比如，为了构建线上交易，需要一个交易下单流程。定义交易下单流程：参数校验 -> 补全信息 -> 价格计算 -> 落库 -> 发送创建订单成功的消息。一个流程就是一条规则。
下单流程还可以扩展得更完整一些：进入店铺 -> 点击商详页 -> 跳转订单确认页 -> 提交订单 -> 支付 -> 跳转订单支付结果页。这个流程涉及更多的基础服务，比如店铺、商品、支付、优惠、物流、会员等。
还可以定义更完整的基本线上交易流程。下单 -> 支付 -> 待发货 -> 已发货 -> 已签收 -> 交易完成； 或者 下单 -> 支付 -> 待发货 -> 退款 -> 交易关闭。
除了流程，规则也指数据项之间的约束。 比如 价格、优惠之间的计算公式，退款校验，不支持的场景等。
关于规则最重要的一个观点是：规则是流动的。 不要拘泥于现有的规则。完全可以创建新的规则。 比如线上交易是一套规则，线下交易又是一套规则，基于社交的交易又是一套规则，将来 AI 普及之后，交易或许产生全新的规则。
如何提取规则呢？ 也需要从代码中提取。
流程。首先，析取最通用的流程作为基础；接着，再看有多出来的或剪裁的或者定制的。比如拼团订单，从已支付到待发货就多出来 待成团 到 已成团 的额外状态流转；比如虚拟商品，支付成功之后就立即变成已发货，不经过待发货。
判断。从代码中的各种 if-else-throw 可以提取出来。
提取规则之后，要仔细思考，为什么要定义这样的规则，其背后的意图和目标是什么？
语义
构建了数据模型和规则之后，为了更好地扩展和发展系统的能力，需要对数据项及规则进行清晰无歧义的语义定义。有三类数据的语义要更加仔细：
- 状态类语义。比如订单状态，通常涉及到业务的流转过程，需要考虑可扩展性；当新增新的业务状态时，能够容易地支持。
- 金额类语义。比如应付金额和实付金额。如果缺乏清晰的语义，在多种业务交叉的情况下，金额类字段就可能有多种理解和取值，很容易导致资金的故障。而资金的故障通常是最严重的故障类别之一。
- 标识类语义。标识类字段用于唯一标识一个实体。
通过“数据模型+规则+语义”，可以勾勒出一个业务系统里的基本业务图景。
项目实战
不下厨，永远学不会做菜。
通过“数据模型+规则+语义”，可以获得对业务的基本理解。不过这种理解往往是模糊不清晰的。通过项目实战，推敲具体的业务实现细节，更深入地理解和扩展现有数据模型、规则、语义的含义及缘由。
对于具体业务，也可以采用这种思维框架来分析。只不过，这些都是基于通用部分而扩展出来的“数据模型+规则+语义”。
小结
本文提出了理解业务的一种有效的思维框架：数据模型+规则+语义。通过“数据模型+规则+语义”，可以勾勒出一个业务系统里的基本业务图景。不局限于工程代码的实现，而是致力于从业务本身的数据、规则和语义去理解，更容易贴近业务真实的意图和目标。