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