前言
名词解释
基础名词
订单金额：用户下单时支付的金额，这个最好理解
产品分成：也就是跟其他人合做以后我方能分到的金额，举个例子，比如用户订单金额是 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实现类似
@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的数据就不能是全局配置了，需要根据订单支付时的商户来找到对应的分成进行统计，但是原有的设计是不是就废弃了，其实并不是，因为可以使用，所以才有了如下的设计
