時隔一年左右，我又來啦！

這次是一個商城項目，還是照例分為三個欄目，項目需求，需求解析和需求實現。

不具體到技術細節，只談論如何實現，以及如何以更好的方式實現。

　　項目需求：

　　首先，需求就是一個商城，有分類，有商品，有購物車，有優惠券，有拼團和眾籌，有訂單管理的商城系統。

但是，這個商城有一個不太一般的功能，就是分銷商功能。

分銷商的功能有很多，也可以管理商品，但是分銷商上傳的商品需要運營人員審核後才可以上架，篩選購買總店的商品，分類和專題商品，

同時分銷商還可以返傭和店鋪折扣，也就是在分銷商的店鋪裏購買，要比總店的折扣來的便宜，同時分銷商店鋪每賣出一件商品，可以返傭。

　　意思就是假如一件商品，總店賣100元，分銷商店鋪可以只賣95元（打95折），同時可以返傭95元的百分之五（4.75）元。

店鋪只有一級層級，好歹減少了一些復雜度。

　　同時還有一個需求，就是因為之前存在 app，需要app那邊的一口價商品可以無縫商家到這個商城中，並且商城要根據app那邊的販賣情況，

上下架商品，也就是app那邊的商品售罄或者下架了，這邊也需要同步下架。

　　需求解析：

　　接下來，就是考慮如何分解項目及內容。

　　這是一個前後端分離的項目，所以我不需要考慮前端的實現，只要做好後臺和接口就行了。

　　1：商品管理，商品需要有上下架，邏輯刪除，首頁推薦和熱門推薦，以及批量設置版本。

　　2：輪播圖，根據時間自動上下架。

　　3：優惠券，只需要滿減優惠券，但是需要有新人禮，根據活動添加限定商品，分類，專題的優惠券，以及優惠券兌換碼兌換優惠券。

　　4：快遞公司，用於快遞100的訂單接口查詢。

　　5：分銷商，分銷商管理和審核商品。

　　6：分類管理，存在三級，一級首頁入口，二級頁面頂部分類，三級專題。

　　7：單頁面，用於微信分享的活動頁面。

　　8：財務管理，分銷商的提現申請和商品購物流水記錄。

　　9：數據統計，用戶數量統計，留存率等，專題統計，統計點擊量和成交量，訂單統計，統計當日成交量等。

　　10：海報，用戶成為分銷商後會生成海報。

　　11：會員折扣，設置用戶成為會員，可以享受全部商品折扣。

　　12：拼團，分2，3，5人，成團可以使用更優惠的價格購買，類似拼多多的拼團功能。

　　13：眾籌，時間限制內有x人購買，則視作眾籌成功，否則則失敗退款。

　　14：設置網站參數等。

　　需求實現：

　　1：商品管理，這部分功能還是比較清楚的，最簡單的做法就是在前端顯示的時候根據對應的字段來表示是否顯示出來。

　　2：輪播圖限時展示，有2種方式，第一種就是在返回json的時候再返回一個時間，可以是時間戳也可以是字符串，反正就是一個轉換的事情，讓前端來控制輪播圖的展示時間，

第二種方式就是查詢當前時間段，處於開始時間和結束時間之內的輪播圖返回給前端，2種方法各有優點。

　　3：優惠券，這裏如果做成可擴展方式的話，優惠券表要設計成 滿減，折扣，立減等等，給優惠券增加類型，然後通過類型來判斷優惠券的類型，根據對應類型來計算優惠方式，

優惠券自身有開始時間，結束時間 ，根據這些狀態來設置優惠券的使用時間和狀態，然後用戶領取優惠券就是一個多對多的關系，然後在關系中也保存開始時間，結束時間，

使用狀態等，這樣設計有一個好處，就是 通過code 獲取優惠券的功能的時候，數據表只需要增加一個code 就可以擴展出這個功能。

　　4：這裏使用快遞一百的接口，需要傳快遞公司編號和快遞單號才可以查詢，所以這裏創建了一個快遞公司表來保存快遞編號，如果不嫌麻煩的話，也可以直接在訂單裏保存

快遞公司編號。

　　5：分銷商，算是核心功能吧，總後臺可以管理分銷商，審核分銷商上傳的商品等，但是技術上沒有什麽關鍵的要點，無非就是用戶登陸店鋪的時候，傳遞一個id 代表分銷商的id，

通過這個id 來保存訂單分銷數據，返傭等等。分銷商有一個分銷後臺，通過這個後臺來處理訂單，商品管理等，總的來說分銷商除了不能修改頁面的板塊之外，其實能夠操作的地方

有很多。

　　6：可以按照樹狀結構來保存，但是開發時說明了只有3個分類，所以就弄了3個表，因為存在分銷商的關系，所以如果單表的話，查詢語句的復雜度太高了，數據庫的查詢性能可能

存在問題。

　　7：可能沒什麽好說的，就是後臺上傳一些圖文等，在前端根據id來顯示。

　　8：財務管理，分銷商提現也沒什麽好說的，無非就是校驗寫的全一些，流水會在用戶關鍵操作的時候記錄。　　

　　9：數據統計，這各部分就是sql語句比較復雜，總的來說就是根據訂單表和用戶來做連接查詢。

　　11：會員折扣，在準備生成訂單和生成訂單的時候校驗這個折扣，同時也是一個多對多關系。

　　12：拼團功能可以說是比較復雜的，首先要設置團購商品，然後分為幾個成團區間，比如2人，3人，5人等，成團後生成訂單，然後就可以走訂單的流程。

順便說一句，有增加機器人的需求，所以這裏 團商品是一個表， 團是一個表，團內成員是一個表，然後通過團來生成訂單，這樣就可以避免也生成機器人的訂單，造成統計或流水出現錯誤。

　　13：眾籌，眾籌是一個弱化版的拼團， 所以是商品一個表，然後就直接生成訂單了，就算眾籌失敗，直接退款即可，成功的話就是走後臺訂單的處理流程。

　　14：網站參數也沒什麽可說的。

所以這個項目就是我在目前公司的第一個實際接手的項目，雖然不算從零開發，但是也折騰了我好久，因為使用的技術太老舊了，操作起來不是很方便，又因為存在分銷商和會員金額結算，

導致項目耦合度也非常高，WebForm+Ado.Net 10年前的項目大概是這麽開發的吧。

總的來說，沒有什麽高技術需求，但是復雜度特別高。

明天還有一篇項目解析。

我的工作生涯中關於項目的需求和功能分析(商城項目)