架构设计之三种业务模型:活动资源模型、契约模型、模板模型
JAVA前线
欢迎大家关注公众号「JAVA前线」查看更多精彩分享，主要内容包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时也非常欢迎大家加我微信「java_front」一起交流学习
在实际开发场景中业务需求各式各样，在技术方案设计阶段，架构师的工作就是将业务语言翻译为技术语言。
业务场景多种多样，但是架构师需要发现不同业务相通之处，抽象成通用模型，这样后续再遇到需求，即使业务场景大相径庭，也可以使用同一套模型应对。本文分析三种业务模型：
- 活动资源模型
- 契约模型
- 模板模型
2 活动资源模型
2.1 业务场景
商家A总共准备发放一种满100减10元优惠券100张，商家A有5家店铺，每个店铺优惠券发放规则各不相同：
- 店铺1：每人限领1张
- 店铺2：每人限领2张
- 店铺3：只允许A城市用户领券
- 店铺4：只允许新用户领券
- 店铺5：只允许B城市C区老用户领券
2.2 模型分析
2.2.1 资源
各个店铺发放优惠券规则不同，但是优惠券只有一种，所以不可能将规则沉淀在优惠券，这就引出本文第一种模型：活动资源模型。优惠券作为一种资源只承载最本质属性：
- 发放张数
- 优惠类型（满减/满折）
- 优惠金额
- 折扣比例
- 使用门槛金额
- 有效期
发放张数控制资源总成本，需要仔细评估。
2.2.2 活动
那么店铺不同的发放规则在哪里体现？答案是活动领域。每个店铺可以根据经营策略，设置本店铺营销活动和不同活动规则，本例中各个店铺可以设置各种活动规则，但是共享同一份资源（100张优惠券）常见活动规则：
- 活动开始时间
- 活动截止时间
- 资源领取类型（系统发放/手动领取）
- 每人允许参与活动次数
- 允许参与用户规则
- 允许参与城市规则
- 允许参与商品规则
- 活动资源规则：每人允许领取X张资源
2.3 数据模型
2.3.1 资源相关
-
优惠券表
- 资源本质属性
-
优惠券领取流水表
- 资源领取记录
-
优惠券使用流水表
- 资源使用记录
-
优惠券使用明细表
- 订单优惠明细
2.3.2 活动相关
-
活动表
- 活动本质属性
-
活动资源规则表
- 每人允许领取X张资源
-
活动地区规则表
- 允许参与活动地区信息
-
活动用户规则表
- 允许参与活动用户信息
-
活动商品规则表
- 允许参与活动商品信息
3 契约模型
3.1 业务场景
商品A每个5元，用户购买3个并下单成功，但是还没有付款。此时卖家对商品价格做出调整改为每个100元，那么用户再付款时，应该付15元还是300元？
3.2 模型分析
订单本质上是一种契约，一旦签订（下单）核心信息就不允许更改。当时用户签订契约是每个5元，即使后续调整为每个100元，也不应该影响已签订契约。
既然契约具有不可变性，那么契约对象就要保存签订时刻各类快照信息，订单就是一种非常典型的契约对象。
3.3 数据模型
本章节以订单模型为例介绍契约模型，这种模型特点是集各类快照大成，所有涉及信息都需要保留快照便于追溯。
3.3.1 基本信息
- 订单编号
- 业务类型
- 下单渠道
- 下单时间
- 订单状态
- 商家Id
- 店铺Id
- 下单用户Id
3.3.2 支付与促销信息
- 支付方式（支付宝/微信/银行卡）
- 支付单号
- 支付账户
- 应付金额
- 实付金额
- 使用优惠券Id
- 优惠券抵扣金额
- 用户权益抵扣金额
- 参与促销活动Id
- 营销活动抵扣金额
- 运费金额
3.3.3 物流信息
- 配送方式（物流/同城/自提）
- 配送公司
- 收货省、市、区
- 收货详细地址
- 收货人电话
- 快递单号
- 自提省市区
- 自提详细地址
- 自提商家电话
3.3.4 商品明细
- 子订单Id
- 子订单状态
- skuId
- skuTitle
- 购买数量
- 销售单价
- 实付单价
- 实付总金额
- 分摊优惠券金额
- 分摊用户权益金额
- 分摊促销活动金额
3.4 漫长的流程
契约模型要记录如此多的快照信息，意味着契约系统需要与很多系统交互，例如在使用优惠券时，订单系统要询问优惠券系统能不能用优惠券。在用户支付时需要与支付系统交互，并等待支付系统回调。在用户支付完成15分钟后将订单下推至调度中心，进行发货调度。这也就意味着契约系统复杂度要比一般系统高。销售层订单一般流程：
- 用户下单
- 风控校验
- 获取商品信息
- 获取优惠券
- 获取促销活动
- 获取用户权益
- 锁定库存（调度中心）
- 计算运费（物流系统）
- 生成不可见订单
- 扣减库存
- 扣减优惠券
- 扣减用户权益
- 占用活动资格
-
订单可见（待支付）
- 支付订单（已支付）
- 订单下推
- 物流发货
- 用户签收（已完成）
- 用户评价
4 模板模型
4.1 业务场景
商家可以设置不同城市的运费模板：
-
A城市：按件数计费
- 首重：2件
- 首费：1元
- 续重：1件
- 续费：1元
-
B城市：按重量计费
- 首重：3公斤
- 首费：1元
- 续重：2公斤
- 续费：1元
商家可以将商品与运费模板绑定，购买商品时读取运费模板计算运费。
4.2 模型分析
模板作用是定义规则，模板模型的作用是将业务对象与规则解耦，规则定义在模板，再与业务对象绑定。这样做有两个优点：第一是规则与业务对象解耦，第二是模板可以复用，相同规则不用重复设置。
我们可以对比模板模型与契约模型：契约模型是一旦签订，无论契约中原始数据如何变化，都不会改变契约。但是模板模型，业务对象在形成契约之前，需要实时感知模板内容变化，例如在下单前，商品绑定的运费模板续费调整，需要重新计算价格。
4.3 数据模型
-
模板表
- 定义规则
-
业务对象与模板关系表
- 建立业务对象与模板关系
5 文章总结
在设计技术方案时虽然需求表面各式各样，作为架构师需要思考能否抽取共通之处，本文介绍了三种常见的业务模型：活动资源模型、契约模型、模板模型。
活动资源模型中资源只设置资源本质属性，活动灵活控制规则。契约模型中一旦契约签订不允许再改变，这也意味着契约需要记录大而全的信息。模板模型中模板定义规则，业务对象绑定模板，并且需要实时感知模板变化。
JAVA前线
欢迎大家关注公众号「JAVA前线」查看更多精彩分享，主要内容包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时也非常欢迎大家加我微信「java_front」一起交流学习