前 言

?上一期?內容我們整體了解了分庫分表實戰項目當前使用的系統架構，也就是單庫版本訂單系統的系統架構。同時，我們也知道了未來要做的分庫分表版本的訂單系統架構。現在，我們就從單庫版本的訂單系統開始，一步一步的來進行優化。

如果想要優化單庫版本的訂單系統，首先要了解目前的訂單系統有哪些核心功能，核心功能的業務流程是什么。

如果你剛入職了這家初創型互聯網公司，而你所在的部門又剛好是做外賣APP的訂單系統的，那你認為入職之后要干的第一件事是什么呢？

必須是了解整個訂單系統，你的leader可能會直接給你發個wiki，這個wiki中包含了單庫版本的系統架構圖，如下圖：

通過這張系統架構圖，可以知道整個訂單系統目前有哪些核心功能，都使用了哪些技術棧。

并且，在這個wiki中除了有系統架構圖之外，還有很多核心接口的業務流程圖，通過這些業務流程圖，可以快速了解到訂單系統核心接口的業務流程。

那訂單系統中，有哪些核心接口的業務流程圖？現在，我們一起來看一下。

用戶下單流程

大家或多或少都是點過外賣的，訂單系統涉及用戶和商家兩個角色的功能，先來看一下C端，即用戶端的一些業務流程，首先就是用戶下單的操作。

用戶可以在外賣APP中點外賣，當用戶選中一個商品之后，會提交訂單，接著就會發起一個創建訂單的請求，如下圖：

可以看到，創建訂單的請求首先會轉發給Controller組件，Controller組件再把請求交給Service組件處理，在Service組件中會先生成一個訂單號，然后為新的訂單組裝好訂單信息以及訂單明細信息。

隨后，Service組件再將組裝好的訂單信息轉交給Repository組件處理，Repository組件通過Mapper組件，最終將訂單的信息保存到數據庫中。

當然，用戶正式下單之后，是需要支付訂單的，但是支付相關的功能，這里可以暫時不用關注。

用戶查詢訂單列表流程

當用戶完成下單之后，用戶可能要看一下自己曾經下過哪些訂單，所以，訂單系統還支持訂單列表查詢，如下圖：

可以看到，用戶可以向外賣訂單系統，發起一個查詢訂單列表的請求，請求同樣先轉發到Controller組件上，因為是查詢訂單列表的信息，所以我們只需要傳遞查詢的參數即可。

然后，Controller組件會把請求參數，通過Service組件傳到Repository組件上，然后Repository組件可以調用Mapper組件的接口，再到數據庫中查詢用戶的所有訂單信息，查詢結果最后會形成一個訂單列表，最后一步步返回給用戶。

最終，用戶就可以從訂單列表中，看到自己下過的所有訂單信息了。

用戶查看訂單詳情流程

如果用戶還想要看下某個訂單里面的詳細信息，此時業務流程圖如下所示：

可以看到，查詢訂單明細請求會先轉發到Controller組件上，然后Controller組件把請求交給Service組件處理。

隨后，Service組件攜帶著訂單號，將查詢訂單明細的請求交給Repository組件來查詢，Repository組件根據訂單號調用Mapper組件的接口，接口會到數據庫中查詢訂單及訂單明細的信息，最后將查詢出來的訂單明細信息返回給用戶。

用戶取消訂單流程

另外，用戶下單之后也是支持取消訂單的，當用戶要取消一個訂單時，也會發送一個取消訂單的請求，如下圖：

如所有請求一樣，取消訂單的請求首先發送給Controller組件，Controller組件會將請求交給Service組件處理，Service組件會把需要取消訂單的訂單號發送給Repository組件，Repository組件拿著訂單號調用Mapper組件中的接口，更新訂單將訂單取消掉。

現在，外賣訂單系統中，C端也就是用戶端的一些操作我們已經了解了，而B端也就是商家的功能，和用戶端的功能是比較類似的。

商家也會查看訂單列表以及訂單的明細信息，而且，當用戶下單之后，商家可以選擇接單或者拒接，一旦商家選擇接單，那么訂單狀態就會變為“已接單”，這些功能在我們的外賣訂單系統中都是支持的。

結束語

最后，在這個wiki中不僅有一堆的流程圖，還有訂單系統代碼倉庫的Git地址，然后你將代碼拉到本地，接著，你一邊看著這些wiki中的業務流程圖，一邊慢慢開始熟悉起來了代碼......