談一談購物車
如題：今天談一談購物車這個話題。
最近在重構購物車，所以借著興頭談一談購物車的設計。
很久很久以前，那個時候還有沒有智能手機，還沒有京東，淘寶也剛剛起步，大概是在上學時讀書看到的，記得書中說購物車是放在session中的，
一同放進session中的還有用戶的信息，然後這個印象這個梗一直深埋心中，始終認為購物車，用戶信息是放在session中。
後來因為多年不做電商，所以這個梗在你心中一直沒有變過，直到近一年多，才發現原來已經過時很久。
現在APP的應用，大數據，分布式技術和一致性協議的開始成熟，session信息和購物車信息開始往持久化方向發展，對那種老古董的架構和設計都是一種沖擊。
如果你不懂歷史，恭喜你，你站在了技術前沿，學習新生的事物，沒有歷史的包袱和思維定式，你一定前途無量。
技術的飛速發展，促使你得不斷的逼迫自己學習新的事物，相信你的積澱能使你在不斷的學習中更加得心應手，對亙古不變的設計運用的爐火純青，是任何人都無法代替的。
今天要談購物車我就是站在這樣的一個時代變遷的和系統重構的時間點上，基於現在我們現有的系統談一談我們的購物車。為什麽為什麽為什麽要重構購物車。
這個問題說起來就又是一個不長不短，不大不小，不痛不癢的歷史問題。
上邊說過了，現在的session信息，購物車信息，越來越趨向於持久化。
我們先不說這個持久化是放在客戶端，比如APP上， 網頁cookie中，還是放在服務器redis或mysql,oracel，或其他什麽數據庫中，我們說一說購物車的數據結構的問題。
今天我們主要就談一談這個數據結構。為什麽要談這個數據結構，因為我認為在這樣一個急功急利的時代，能看到的東西才能吸引人的眼球，才能引起人的註意，
用到程序上說著屬於測試驅動開發模型，從測試開始倒推，該怎麽開發，開發什麽，完成一步倒推一步，直到達到遞歸的結束，開發完成。
我們把這個思想運用到我們的購物車構建上。
那麽我們的購物車是什麽樣子呢，現成的參考模型，淘寶，京東，當當，等等。
然後我們來看，購物車裏的有商品，商品有價格，有數量，商品很有可能參加各種活動，各種活動會影響商品的價格。
用戶還可以使用優惠券和積分，商品中還有禮品，商品還來自不同的倉庫，對於像淘寶，天貓，京東這樣的電商有商家入駐，商品還可以來自不同的商家。
這個可以在購車時不考慮，但是我們一定需要知道。因為既然有這些，我們非常需要按照這些對購物車裏的商品進行分組。
所以這部分是非常值得思考和仔細設計的。
我們不防這樣按實際的情況想一想，一個商家店鋪或者倉庫賣東西，舉行或者不舉行促銷活動，賣商品。
按照這樣的一個思路想下來，我們的購物車大概是可以這樣分類的，首先購物車然後倉庫或者店鋪，然後促銷活動，然後商品。
大概的樹形結構下來應該是：
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等，這些冗余考慮也是為了謹慎，
在沒完全想好如何兼容老系統，如何做出完美的設計前，也不敢冒然不冗余。
歡迎網友討論指正，一起探討，給予指導，不吝賜教。
談一談購物車