談一談購物車

如題：今天談一談購物車這個話題。
最近在重構購物車，因此藉着興頭談一談購物車的設計。
好久好久之前，那個時候還有沒有智能手機，尚未京東，淘寶也剛剛起步，大概是在上學時讀書看到的，記得書中說購物車是放在session中的，
一同放進session中的還有用戶的信息，而後這個印象這個梗一直深埋心中，始終認爲購物車，用戶信息是放在session中。
後來由於多年不作電商，因此這個梗在你心中一直沒有變過，直到近一年多，才發現原來已通過時好久。
如今APP的應用，大數據，分佈式技術和一致性協議的開始成熟，session信息和購物車信息開始往持久化方向發展，對那種老古董的架構和設計都是一種衝擊。

若是你不懂歷史，恭喜你，你站在了技術前沿，學習新生的事物，沒有歷史的包袱和思惟定式，你必定前途無量。
若是你和我同樣，從一個遙遠的時代過來，那麼一樣恭喜你，你看到了歷史的變遷。
技術的飛速發展，促使你得不斷的逼迫本身學習新的事物，相信你的積澱能使你在不斷的學習中更加駕輕就熟，對亙古不變的設計運用的爐火純青，是任何人都沒法代替的。

今天要談購物車我就是站在這樣的一個時代變遷的和系統重構的時間點上，基於如今咱們現有的系統談一談咱們的購物車。爲何爲何爲何要重構購物車。
這個問題提及來就又是一個不長不短，不大不小，不痛不癢的歷史問題。

上邊說過了，如今的session信息，購物車信息，愈來愈趨向於持久化。
咱們先不說這個持久化是放在客戶端，好比APP上， 網頁cookie中，仍是放在服務器redis或mysql,oracel，或其餘什麼數據庫中，咱們說一說購物車的數據結構的問題。
不管你是放在哪裏存儲或者仍是放在session中，購物車必定有本身的一個數據結構。
今天咱們主要就談一談這個數據結構。爲何要談這個數據結構，由於我認爲在這樣一個急功急利的時代，能看到的東西才能吸引人的眼球，才能引發人的注意，
用到程序上說着屬於測試驅動開發模型，從測試開始倒推，該怎麼開發，開發什麼，完成一步倒推一步，直到達到遞歸的結束，開發完成。
咱們把這個思想運用到咱們的購物車構建上。
那麼咱們的購物車是什麼樣子呢，現成的參考模型，淘寶，京東，噹噹，等等。
而後咱們來看，購物車裏的有商品，商品有價格，有數量，商品頗有可能參加各類活動，各類活動會影響商品的價格。
用戶還可使用優惠券和積分，商品中還有禮品，商品還來自不一樣的倉庫，對於像淘寶，天貓，京東這樣的電商有商家入駐，商品還能夠來自不一樣的商家。
這樣看購物車裏的商品在造成訂單時是必定要拆分紅不一樣的訂單，就算是同一個倉庫，不分商家，可是我前邊的文章也說過像保稅倉，香港倉也是須要拆分的。
這個能夠在購車時不考慮，可是咱們必定須要知道。由於既然有這些，咱們很是須要按照這些對購物車裏的商品進行分組。
因此這部分是很是值得思考和仔細設計的。

咱們不防這樣按實際的狀況想想，一個商家店鋪或者倉庫賣東西，舉行或者不舉行促銷活動，賣商品。
按照這樣的一個思路想下來，咱們的購物車大概是能夠這樣分類的，首先購物車而後倉庫或者店鋪，而後促銷活動，而後商品。
大概的樹形結構下來應該是：
ShoppingCart
　　Store
　　　　Activity
　　　　　　Product
這樣想的一個結構應該是能知足不少的使用狀況的，好比：
[京東自營]
　　[活動無，沒有活動固然能夠不顯示活動名字]
　　長白山礦泉水一箱 一箱 20元
　　嶗山白花蛇草水一箱 一箱 56元
[羊之意店鋪]
　　[滿100減30]
　　鋁膜車衣一件 一件 59元
　　洗車水槍一支，贈送3米水管 一支 38元
[馬克華菲官方旗艦店]
　　[買2贈1]
　　白色L號T恤 1件 88元
　　黑色L號T恤 1件 108元
　　[贈品]藍色L號T恤 1件 0元
這樣子是應該能知足購物車的需求的，而後購物車商品選擇完畢後，
進入結算頁面，在結算頁面能夠選擇是否是使用優惠券，減免券之類的，積分之類的，同時計算出需不須要支付郵費。
最後確認，計算最終的價格，使用完優惠券，積分，郵費，等全部的金額，落庫，讓用戶支付。

這就是我想到的一個購物車的結構了，有同事仔細查看過京東的和淘寶的結果，基本大致的設計是同樣的，固然會有差異，但總體思路是同樣的。
我想這些都是成熟的設計和結構，不會逃出設計人員的法眼。

結算確認後直接支付或者先生成訂單，以後再支付，這個淘寶和京東的處理行爲是不同，
他們的不同在於若是用戶同時在一單內購買了不一樣店鋪的商品，先不支付以後再支付，淘寶是能夠分開支付的，而京東是不能分開支付的，
淘寶在生成訂單時制直接拆分是不一樣的兩個或多個訂單，而京東只有在支付後才顯示兩個或多個不一樣的訂單。
我想他們不同可能各自有各自的考量和理由。

在接下來就要談支付和拆單了，支付的問題我在以前談過一個，拆單的問題之後在談。
今天最後的一點時間在說一說，購物車持久化時數據庫的存儲設計。
我以前的文章說過商城活動的設計，結合活動的設計，大概購物車的設計也是不用存活動的信息的，
活動信息由於和時間關係比較緊密，實時查詢可能效果更好，活動信息能夠放內存或緩存中查詢起來會很快，不用擔憂時間效率問題。
那麼購物車的信息可能就是以下這樣:
shoppingcart(
int id pk,
int user_id,

int goods_id,
string warehouse_code,

string sku_code,
string sku_name,
string img_url,
numberic price,
int number,

timestamp create_time,
timestamp update_time
boolean selected
)
大概是這個樣子，能夠看到這裏有一些反設計模式的地方，好比有些冗餘的信息，對goods_id, warehouse_code等，這些冗餘考慮也是爲了謹慎，
在沒徹底想好如何兼容老系統，如何作出完美的設計前，也不敢冒然不冗餘。

 

歡迎網友討論指正，一塊兒探討，給予指導，不吝賜教。