前言
名詞解釋
基礎名詞
訂單金額：用戶下單時支付的金額，這個最好理解
產品分成：也就是跟其他人合做以后我方能分到的金額，舉個例子，比如用戶訂單金額是 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的數據就不能是全局配置了，需要根據訂單支付時的商戶來找到對應的分成進行統計，但是原有的設計是不是就廢棄了，其實并不是，因為可以使用，所以才有了如下的設計
