買了東西，提交訂單，訂單確認的過程，減庫存，減優惠券，減餘額，在操作失敗時，需要回退等
使用者->訂單系統
|--商品服務
|--優惠券服務
|--使用者服務
確認訂單邏輯
1. 校驗合法性
2. 儲存訂單，使用者不可見
3. 減庫存，件優惠券，減於額
4. 確認訂單
|-- 確認成功
|-- 確認失敗
|--傳送失敗訊息到mq
|--庫存服務監聽，回退
|--優惠券服務監聽，回退
|-- 使用者服務監聽，回退
資料庫表
使用者表: id,姓名，密碼，手機號，積分，註冊時間，餘額
餘額日誌表：id，訂單id，型別（付款還是退款），發生金額，建立時間，校驗的時候需要使用，避免重複，或重試
優惠券 ，id，price，userid，orderid，isused，createtime
商品：id，name，goodsnumber，price，goodsdesc，createtime
訂單：orderid，userid，status（未確認，已確認，已取消，無效，退款等），paystatus（未支付，支付中，已支付），shippingstatus（發貨狀態），address，收貨人，商品id，數量，**，總**，運費，訂單**，優惠券id， 優惠券支付金額，已付金額，支付金額，建立時間
訂單商品操作日誌（一定要記錄，備查，校驗使用）：商品id，訂單id，購買數量，建立時間
訂單支付表：支付編號，訂單號，支付金額，是否支付
訊息佇列生成記錄（接收到的mq訊息）：id，groupname，topic，tag，key，body，status（是否處理），建立時間
訊息佇列消費：id，groupname，topic，tag，key，body，status（處理中，成功，失敗），處理次數（總失敗放棄），時間
1. 檢查定時是否存在，校驗不過拋異常
2. 檢查商品是否存在：通過訂單中的商品id，呼叫商品服務查詢商品
3.檢查使用者是否存在：通過訂單中的使用者id，查詢使用者服務
4. 簡單訂單金額是是否合法：是否和商品服務中查詢的**一樣
5 數量是否合法，是否大於庫存等
1. 設定訂單id，隨機不重複的id，需要返回
2. 核算運費，按自己規則
3. 總金額是否合法 ，通過訂單的單價和數量再計算一下**，檢查是否和訂單傳過來的總**一致
4. 是否使用餘額，如果使用，檢視是否合法，和db中儲存的餘額比較，如果沒有使用設定為0，方便計算
5.是否使用優惠券
6.計算應該支付的金額
7.建立時間
8.儲存到db
1. 商品表減庫存 ，這裡的引數可以是日誌記錄表的pojo物件，實現類校驗引數（訂單id，商品id，數量合法等），校驗是否庫存不足等
2. 記錄日誌，可以類似記賬的方式，減庫存記錄負數，加庫存記錄正數
扣減餘額
1. 使用者餘額，可能是支付，可能是退款。這裡需要通過日誌表防止多次付款或者多次退款，需要通過餘額扣減日誌判斷，如果訂單有日誌，不需要再支援，如果訂單有日誌，才可以退款等
2. 記錄日誌
1. 通過mq groupname，tags，keys（訂單id）到mq消費記錄表查詢記錄，如果消費過判斷消費狀態（成功，處理中，失敗）
1. 通過存在mq日誌記錄的情況，處理成功：返回，正在處理：返回：
處理失敗的情況，把狀態修改為正在處理，儲存（加鎖更新）
2. 不存在日誌記錄的情況，直接insert訊息到日誌表，tag，key，狀態，body，msgid等 ，狀態為正在處理
3. 回退庫存
4. 記錄庫存操作日誌
5. 更改mq消費記錄的狀態為處理成功
6. 如果發生異常，需要修改狀態為處理失敗，或者設定最大處理次數
待續。。。
應用邏輯（業務 商業邏輯）抽象出來
那東西主要就是將應用邏輯 業務 商業邏輯 抽象出來，與前端表現介面分開，從而體現三層 多層結構的易拓展 易維護性的特性。業務邏輯又分為業務規則和業務外觀 分開設計的目的是提高應用程式的可伸縮性和可維護性。如果你的應用程式在執行一段時間後，需要修改某些業務規則，你不需要對其它部分做大量的改動，如果你的...
技術討論 電商業務中的業務合併問題
今天第一次寫這個，其實，這些事情在10年前的erp和其他專案中都是有相應的解決方案的。最近在京東採購了兩個單子，遇到了下面的問題 1 發過來的衣服是180 100a的，我只能穿175的，申請換貨。2 數位相機28exr的取景器內特別模糊，而液晶屏很清晰，我確認不是我眼睛的問題，所以，只能申請換貨。京...
電商業務跨境租用香港伺服器優勢
作為跨境電商來說無論是自建平台還是在第三方平台開設店鋪都離不開租用一台可靠的海外伺服器，然而放眼全球租用伺服器既能保證海外使用者的訪問，有能夠方便國內企業進行後台管理，數得上來的也就是香港伺服器了，那麼租用香港伺服器部署跨境電商業務好在哪，這裡泰海董輝就來簡單介紹一下。1 線路互訪無壓力 很多做電商...