這是典型的程式業務處理的方式。——接收到請求入參後，先進行前置校驗，如果校驗失敗直接終止返回，否則才走後面的業務處理流程。 ...
我們來看一個案例。
前端頁面上，用戶在訂單詳情頁確認完信息後，點擊“確認支付”，發起餘額支付。
這裡，我們做如下3項假定。
1）後臺程式暴露的“支付”Rest介面名為 order/pay。
2）後臺程式對於“支付”的處理邏輯，我們簡化成下麵的業務流程。
3）後臺程式是微服務結構，包括提供RestAPI介面的springmvc服務和後面的訂單服務、賬戶服務。
那麼，下麵兩種實現，你選擇哪一種？
比較上面兩種實現方式，第一種是在order/pay這個rest介面里先校驗訂單狀態，通過後才調用訂單服務的“支付訂單”介面。 第二種是直接轉發請求給訂單服務的“支付訂單”介面。
相比來說，第一種更靠譜一些。
Why？
看上去，雖然兩種實現方式都能達到目的，第一種方式還多了一個前置的校驗。為什麼我建議採用第一種方式呢？
這是典型的程式業務處理的方式。——接收到請求入參後，先進行前置校驗，如果校驗失敗直接終止返回，否則才走後面的業務處理流程。
有同學就說了，直接調用訂單服務的“支付訂單”介面，“支付訂單”介面的實現里不是也有訂單狀態的前置校驗嗎？
從技術的角度來說，這是有區別的。“支付訂單”作為一個業務處理介面，我們要做的控制會比較多，例如日誌、耗時、冪等、鎖等。因此，從這個角度來說，在需要支付訂單的時候再調用，是不是更合理呢？
類似的案例，也包括，我們的mq消費者，在從隊列里拿到消息後，先進行必要的判斷和校驗，然後再調用業務方法。而不是一上來就直接把參數丟給業務方法。
本文設計文稿自：https://www.processon.com/view/link/611e38c2e0b34d3511f7c479
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/17765857.html
