架构设计之三种业务模型:活动资源模型、契约模型、模板模型

JAVA前线 

欢迎大家关注公众号「JAVA前线」查看更多精彩分享，主要内容包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时也非常欢迎大家加我微信「java_front」一起交流学习

1 文章概述

在实际开发场景中业务需求各式各样，在技术方案设计阶段，架构师的工作就是将业务语言翻译为技术语言。

业务场景多种多样，但是架构师需要发现不同业务相通之处，抽象成通用模型，这样后续再遇到需求，即使业务场景大相径庭，也可以使用同一套模型应对。本文分析三种业务模型：

• 活动资源模型
• 契约模型
• 模板模型

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」一起交流学习