訂單的創建一般都會包含金額支付的業務場景，而金額的支付的業務場景我這里分為了線下、線上兩種支付方式。線下的支付方式包括現金支付，充值消費；線上則是微信，支付寶，銀聯，paypal，銀行卡支付等等此類。
? 線下的支付是程式的執行方式是順序執行，資料的處理邏輯是一個獨立的整體；而線上的支付則基本分為三步：
? 1、下單
? 先在訂單系統中創建一個等待支付的訂單，獲取訂單資訊。
? 2、支付
? 根據訂單資訊，呼叫支付三方的介面或SDK生成支付所需資料，以二維碼或其他方式讓用戶發生在線支付。
? 3、等待回呼
? 在第二步請求前，或請求中傳遞的引數中帶有了，三方支付回呼時呼叫的本系統服務介面的地址，在此介面中，進行驗證回呼資料的正確性，訂單狀態的修改，以及后續訂單開通的服務。
? 至此，訂單支付算是基本完成。但是用戶購買完訂單相應的服務（日用商品除外）后，要享受或使用該服務時，該服務的享受記錄，或是否已享受的資料該什么時候寫入呢，這個是個思考的問題。
? 第一種思考：
? 創建訂單時就做記錄，這個有點不太合理，創建訂單時，用戶并沒有付費，就有了記錄，業務嚴謹性有問題，PASS。
? 第二種思考：
? 訂單支付完成后馬上做記錄，這個還行，但是要分兩種情況處理，因支付方式不同，線下支付是在支付完成后順序在程式中增加處理； 而線上支付則要在回呼介面中增加處理。或者封裝到服務開通中進行統一處理。這個時候新增的資料都是待使用的狀態，等待用戶使用服務時更新狀態即可。這個方案在用戶使用服務時回應很快，但是在下單時，可能因為下單修改的資料太多而影響到下單支付的回應速度。各有利弊，具體看業務場景中的下單涉及的資料量多少。
? 第三種思考：
? 訂單支付完成后不做新增，當用戶使用服務時新增服務使用記錄資料，這種方案把整個服務分為了購買和售后兩塊來做，業務上比較清晰明了，資料上處理起來也算獨立吧，這個方案不錯，可以對于下單時涉及修改資料太多而造成回應慢的情況，做此方案執行，可能會提高一定效率，而用戶使用服務時，因資料量也就一個資料，回應也不可能太慢的。
?
綜上所述，訂單創建后的資料準備應該是在用戶使用服務時寫入，而不是提前寫入。
后話：我使用第二種思考來做是為了后續查看服務的使用情況時好查找，而使用第三種思考時要多繞一道彎來做查詢，顯得有點麻煩，但是第三方思考的方案他資料準確啊，依據訂單查詢的結果，資料全面且準確，后續可適用于多個業務場景。
uj5u.com熱心網友回復：
第三種方案相對于方案二還有個優點是在退款的業務中比較獨立，不會產生無用的資料轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/248812.html
標籤：應用服務器