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

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