理解业务的思惟框架：数据模型+规则+语义

规则是流动的。 互联网的美妙，在于能够重构规则，从而革新现有的一切。

概述

中大型业务系统中，每每多种业务相互交叉，错综复杂，使得系统变得难以理解。通常的方法是，经过阅读工程代码来理解系统。但这种方法是有局限性的。由于工程代码，每每是系统设计实现与业务的混合体，并不彻底一致地表达着业务自己：

• 因为当时的技术和系统架构的限制，每每实现的并非最优的业务视角，而是折衷过的；
• 部分代码写得比较蹩脚，表达不许确，甚至有 BUG ，反而妨碍真正理解业务自己。

要真正理解业务，须要从业务自己上去理解，严格区分出“业务规则”与“系统设计与实现”这两个不一样的层面。工程代码，能够做为重要的参考。

三要素

数据模型

数据模型指的是，须要哪些数据项，数据项之间的关联，如何有序地组织这些数据项。数据模型是软件总体设计的导航图。肯定良好的数据模型，设计就成功了一大半。

好比交易的基本数据模型以下。经过这个模型，能够全局式地概览交易所涉及到的各类基本数据、各个基础模块，有一个总体而基本的把握。

针对具体业务，则可更容易地理解和分析。具体业务的数据模型，一般是基础数据模型再加上一些扩展性的数据集。

如何提炼数据模型呢 ？

能够从工程代码里的各类 DO，DTO ，服务接口返回的数据对象入手。推敲每一个字段的含义，将其进行归类。这时候，采用的是有选择性地阅读，阅读代码呈现的关键对象，而不是在荆棘丛生的代码中穿梭，弄的遍体鳞伤。

规则

规则指的是，数据项及流程要知足什么约束 ？为了什么目标而服务 ？

好比，为了构建线上交易，须要一个交易下单流程。定义交易下单流程：参数校验 -> 补全信息 -> 价格计算 -> 落库 -> 发送建立订单成功的消息。一个流程就是一条规则。

下单流程还能够扩展得更完整一些：进入店铺 -> 点击商详页 -> 跳转订单确认页 -> 提交订单 -> 支付 -> 跳转订单支付结果页。这个流程涉及更多的基础服务，好比店铺、商品、支付、优惠、物流、会员等。

还能够定义更完整的基本线上交易流程。下单 -> 支付 -> 待发货 -> 已发货 -> 已签收 -> 交易完成； 或者 下单 -> 支付 -> 待发货 -> 退款 -> 交易关闭。

除了流程，规则也指数据项之间的约束。 好比 价格、优惠之间的计算公式，退款校验，不支持的场景等。

关于规则最重要的一个观点是：规则是流动的。 不要拘泥于现有的规则。彻底能够建立新的规则。 好比线上交易是一套规则，线下交易又是一套规则，基于社交的交易又是一套规则，未来 AI 普及以后，交易或许产生全新的规则。

如何提取规则呢？ 也须要从代码中提取。

• 流程。首先，析取最通用的流程做为基础；接着，再看有多出来的或剪裁的或者定制的。好比拼团订单，从已支付到待发货就多出来 待成团 到 已成团 的额外状态流转；好比虚拟商品，支付成功以后就当即变成已发货，不通过待发货。

• 判断。从代码中的各类 if-else-throw 能够提取出来。

提取规则以后，要仔细思考，为何要定义这样的规则，其背后的意图和目标是什么？

语义

构建了数据模型和规则以后，为了更好地扩展和发展系统的能力，须要对数据项及规则进行清晰无歧义的语义定义。有三类数据的语义要更加仔细：

• 状态类语义。好比订单状态，一般涉及到业务的流转过程，须要考虑可扩展性；当新增新的业务状态时，可以容易地支持。
• 金额类语义。好比应付金额和实付金额。若是缺少清晰的语义，在多种业务交叉的状况下，金额类字段就可能有多种理解和取值，很容易致使资金的故障。而资金的故障一般是最严重的故障类别之一。
• 标识类语义。标识类字段用于惟一标识一个实体。
  
  

经过“数据模型+规则+语义”，能够勾勒出一个业务系统里的基本业务图景。

项目实战

不下厨，永远学不会作菜。

经过“数据模型+规则+语义”，能够得到对业务的基本理解。不过这种理解每每是模糊不清晰的。经过项目实战，推敲具体的业务实现细节，更深刻地理解和扩展示有数据模型、规则、语义的含义及原因。

对于具体业务，也能够采用这种思惟框架来分析。只不过，这些都是基于通用部分而扩展出来的“数据模型+规则+语义”。

小结

本文提出了理解业务的一种有效的思惟框架：数据模型+规则+语义。经过“数据模型+规则+语义”，能够勾勒出一个业务系统里的基本业务图景。不局限于工程代码的实现，而是致力于从业务自己的数据、规则和语义去理解，更容易贴近业务真实的意图和目标。