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

前言

名词解释

基础名词

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

产品分成：也就是跟其他人合做以后我方能分到的金额，举个例子，比如用户订单金额是 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拆开进行处理，才能符合。

需要解决的问题

拆开LTV和ROI逻辑，不讲
历史的LTV数据迁移，看情况而地
新的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实现类似

    @Override
    public int getCode() {
        return ProductSubTypeEnum.ANDROID.getCode();
    }

    @Override
    public double doDeductCostAmount(OrderInfo orderInfo, DeductCostVo deductCostVo, double productDividedRatio, double finalDividedRatio, boolean applePay, boolean aliPay, boolean webPay)


CostStrategyComponent： 对外暴漏类


@Resource
    private 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的数据就不能是全局配置了，需要根据订单支付时的商户来找到对应的分成进行统计，但是原有的设计是不是就废弃了，其实并不是，因为可以使用，所以才有了如下的设计