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