设计模式使用（成本扣除）

前言

名词解释

基础名词

订单金额：用户下单时支付的金额，这个最好理解

产品分成：也就是跟其他人合做以后我方能分到的金额，举个例子，比如用户订单金额是 100 块，我方的分成是 80%，那么也就是我方能得到 80 块

联运商分成：跟产品分成类似，就是说我方还需要分去一部分的前给联运商（比如广告商，巨量，快手等），一般是不高的，也就10%左右

综合例子：订单金额 100 块，产品分成 80%，联运商分成10%，那么最终我方得到的金额就是如下的计算公司 100 * （80 -10）%  = 70 块

行业名词

LTV：表示用户在时间段内的下单增长情况，比如第1天下了100块，第二天下了200块。然后去除以注册用户

ROI：类似于LTV的算法，只不过金额部分需要减去分成的情况，也就是第1天70块，第二天下了140块，然后去除以消耗的金额

原有设计

         原来的LTV和ROI是使用的同一张表格，里面的金额存的是用户的真正金额，获取LTV的时候就直接拿出来即可，而在获取ROI的时候就是结合金额*分成比例（提前算好入库的）

        也不能说这样有问题，但是这种算法就只能适应分成比例不变的情况下

目前需求

        之前由于分成比例是固定不变的，但是现在ROI分成金额还需要增加微信、支付宝的分成，而用户选择支付宝还是微信支付是人为不可控的，因此需要把LTV和ROI拆开进行处理，才能符合。

需要解决的问题

        1. 拆开LTV和ROI逻辑，不讲

        2. 历史的LTV数据迁移，看情况而地

        3. 新的ROI表设计，核心，主要还是讲设计模式的运用

问题解决

 首先算法如下，可以看到还区分IOS和安卓，以及切支付（这里就不细说了，主要讲设计思路）

按不同维度统计的总充值*（产品分成比例-联运商分成比例-支付宝/微信） 安卓

按不同维度统计的总充值（产品分成比例-联运商分成比例） iOS
按不同维度统计的总充值（产品分成比例-支付宝/微信） iOS切支付

设计模式-策略模式使用

设计图如下

AbstractCostStrategy 抽象类//处理类型public abstract int getCode();protected abstract double doDeductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, double productDividedRatio, double finalDividedRatio, boolean applePay, boolean aliPay, boolean webPay);public double deductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, GameProduct gameProduct)AndroidCostStrategyImpl 安卓实现，IOS实现类似@Overridepublic int getCode() {return ProductSubTypeEnum.ANDROID.getCode();}@Overridepublic double doDeductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, double productDividedRatio, double finalDividedRatio, boolean applePay, boolean aliPay, boolean webPay)CostStrategyComponent： 对外暴漏类@Resourceprivate List<AbstractCostStrategy> abstractCostStrategyList;public AbstractCostStrategy getCostStrategy(GameProduct gameProduct) 主要是动态控制变化，不写死public class DeductCostVo {//支付宝分成private double aliDivide;//微信分成private double webDivide;
}

设计描述

        其实关键在于AbstractCostStrategy的设计，可以看到deductCostAmount是public的，也就是对外使用的，而通用的逻辑被放置在了这里，而doDeductCostAmount是一个抽象的方法，也就是子类需要实现的，具体因安卓和IOS不同，getCode就是子类来进行实现的

        DeductCostVo的结构主要是为了不写死分成，搞成可配置的

        CostStrategyComponent主要是为了使用端不需要介入系统内部逻辑而设计的

        这样其实就已经完成了设计，到这里本来就已经完成了，但是中途需求方又发生了变化，需要根据每个具体的商户进行分成统计，也就是说订单支付到哪个具体的商户号其实也是不定的，那么DeductCostVo的数据就不能是全局配置了，需要根据订单支付时的商户来找到对应的分成进行统计，但是原有的设计是不是就废弃了，其实并不是，因为可以使用，所以才有了如下的设计