購(gòu)物車(chē)下單和商品直接購(gòu)買(mǎi)，有很大的不同骂因，其中最大的不同點(diǎn)就是購(gòu)物車(chē)下單可以同時(shí)購(gòu)買(mǎi)多種商品炎咖，并且購(gòu)物車(chē)中的商品還會(huì)按照不同的屬性進(jìn)行分組，生成不同的訂單寒波，對(duì)應(yīng)不同的發(fā)貨流程乘盼，這里先不考慮那么復(fù)雜的場(chǎng)景，先從簡(jiǎn)單的設(shè)計(jì)俄烁。
首先绸栅，我們要知道，在普通的電商項(xiàng)目中页屠，每個(gè)用戶都有唯一一個(gè)購(gòu)物車(chē)（shopping_cart）粹胯，購(gòu)物車(chē)會(huì)顯示商品數(shù)量，商品總價(jià)格等信息辰企，那么來(lái)設(shè)計(jì)一下購(gòu)物車(chē)的表結(jié)構(gòu)
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| id | num | 購(gòu)物車(chē)id |
| item_count | num | 商品總數(shù) |
| selected_item_count | num | 選中的商品總數(shù) |
| total_price | num | 購(gòu)物車(chē)中選中商品的實(shí)際總價(jià)格 |
| real_total_price | num | 購(gòu)物車(chē)中選中商品的優(yōu)惠后總價(jià)格 |
| order_count | num | 購(gòu)物車(chē)中訂單數(shù)量 |
| select_order_count | num | 購(gòu)物車(chē)中勾選的訂單數(shù)量 |
| uid | num | 用戶id |
上面對(duì)應(yīng)的就是一個(gè)簡(jiǎn)單的購(gòu)物車(chē)字段結(jié)構(gòu)风纠，由于先不考慮商品分組，優(yōu)惠信息等情況蟆豫，暫時(shí)先設(shè)計(jì)這些字段
按照上面的設(shè)計(jì)，當(dāng)一個(gè)用戶創(chuàng)建的時(shí)候懒闷，就會(huì)產(chǎn)生一個(gè)專(zhuān)屬于這個(gè)用戶的購(gòu)物車(chē)
初始化的購(gòu)物車(chē)信息
{
"id": 1299477521234563,
"item_count": 0,
"selected_item_count":0,
"total_price": 0,
"real_total_price": 0,
"order_count": 0,
"select_order_count": 0,
"uid": 123456
}
下面我們要將商品添加到購(gòu)物車(chē)中
順著文章一的設(shè)計(jì)十减，添加商品的時(shí)候，生成一個(gè)訂單order愤估，并將相應(yīng)的價(jià)格信息更新到購(gòu)物車(chē)數(shù)據(jù)中帮辟，并且正常情況下添加進(jìn)購(gòu)物車(chē)的訂單都是被選中的，此時(shí)我們要在order中追加兩個(gè)字段
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| shopping_cart_id | num | 購(gòu)物車(chē)id（通過(guò)該id將購(gòu)物車(chē)和訂單關(guān)聯(lián)） |
| is_selected | num | 訂單是否被選中（0=未選中玩焰，1=選中）默認(rèn)是1 |
此時(shí)將一個(gè)商品添加進(jìn)購(gòu)物車(chē)后由驹，相應(yīng)的生成的訂單數(shù)據(jù)結(jié)構(gòu)如下
{
"id": 1299477521523456,
"state": 0,
"item_id":1299477521563661,
"name": "可口可樂(lè)",
"sub_name": "可口可樂(lè)真好喝",
"title_pics": ["我是圖片連接","我是圖片連接"],
"total_count": 10,
"item_price": 1,
"settlement_price": 100,
"uid": 123456,
"shopping_cart_id":1299477521234563,
"is_selected":1
}
此時(shí)的購(gòu)物車(chē)數(shù)據(jù)如下
{
"id": 1299477521234563,
"item_count": 10,
"selected_item_count":10,
"total_price": 100,
"real_total_price": 100,
"order_count": 1,
"select_order_count": 1,
"uid": 123456
}
由于這里還未設(shè)計(jì)優(yōu)惠信息，所以total_price和real_total_price的值是相同的昔园，后續(xù)關(guān)于優(yōu)惠信息的文章會(huì)講解這一部分
接下來(lái)對(duì)購(gòu)物車(chē)的操作分一下幾種情況
- 將多種商品添加進(jìn)購(gòu)物車(chē)蔓榄，創(chuàng)建新的
order并更新購(gòu)物車(chē)中的數(shù)據(jù)信息 - 刪除某個(gè)商品，將對(duì)應(yīng)的
order刪除并更新購(gòu)物車(chē)中數(shù)據(jù)信息 - 對(duì)購(gòu)物車(chē)中的訂單進(jìn)行選中或未選中操作做默刚，更新
order中的is_selected值甥郑，并對(duì)購(gòu)物車(chē)的數(shù)據(jù)信息進(jìn)行更新 - 修改某個(gè)商品數(shù)量，更新對(duì)應(yīng)
order信息荤西，并更新購(gòu)物車(chē)數(shù)據(jù)信息
接下來(lái)是將選中的商品從購(gòu)物車(chē)中提取出來(lái)澜搅，生成即將支付的訂單伍俘，此時(shí)或許已經(jīng)發(fā)現(xiàn)了問(wèn)題，我們不能再生成order了勉躺，一方面order的設(shè)計(jì)不滿足多種商品的訂單要求癌瘾，另一方面再生成order，無(wú)法區(qū)別購(gòu)物車(chē)訂單和支付訂單的區(qū)別饵溅，這時(shí)要再設(shè)計(jì)一種訂單妨退，姑且叫總訂單（user_order），實(shí)際上前后端展示在用戶界面的是這個(gè)user_order的數(shù)據(jù)信息
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| id | num | 總訂單id |
| uid | num | 用戶id |
| state | num | 訂單狀態(tài)：-2=訂單支付失效（未在指定時(shí)間內(nèi)支付）概说；-1=刪除碧注；0=在購(gòu)物車(chē)中；1=待付款糖赔；2=已支付（代發(fā)貨）萍丐；3=已發(fā)貨（待收貨）；4=待評(píng)價(jià)放典；5=交易完成逝变；6=已取消；7=維權(quán)中（退款中）奋构；8=訂單關(guān)閉（全額退款）壳影；9=部分退款（維權(quán)成功）；10=退款拒絕（維權(quán)失斆志省） |
| total_price | num | 訂單總價(jià)格（含商品費(fèi)用宴咧，運(yùn)費(fèi)，保險(xiǎn)費(fèi)用等径缅，再減去優(yōu)惠的價(jià)格） |
| item_total_price | num | 商品總價(jià)格 |
| ship_fee | num | 郵費(fèi) |
| sub_order_count | num | 子訂單數(shù)量 |
這里只是列舉了重要字段掺栅，實(shí)際上user_order中還有很多信息，例如優(yōu)惠減免價(jià)格纳猪、是否支持退貨氧卧、收貨地址id（對(duì)應(yīng)查找收貨地址信息）、改簽狀態(tài)等
那么氏堤，當(dāng)從購(gòu)物車(chē)中提取商品訂單order生成總訂單user_order的時(shí)候沙绝，我們生成的user_order大致是這樣的
{
"id": 1299477521238888,
"uid": 123456
"state": 1,
"total_price":105,
"item_total_price": 100,
"ship_fee": 5,
"sub_order_count": 1
}
此時(shí)購(gòu)物車(chē)勾選出的商品訂單order中要再追加一個(gè)字段
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| user_order_id | num | 總訂單id（通過(guò)該id將總訂單和子訂單關(guān)聯(lián)） |
那么我們總結(jié)一下，當(dāng)從購(gòu)物車(chē)中選出商品鼠锈，形成支付信息的時(shí)候要做的操作
- 生成總訂單
user_order闪檬，再次強(qiáng)調(diào)，實(shí)際前后臺(tái)顯示在用戶面前的是user_order中的信息购笆，這個(gè)很重要 - 更新
order中的state字段為1（表示訂單已經(jīng)不是購(gòu)物車(chē)訂單）谬以，并在order中追加字段user_order_id - 更新
shopping_cart相關(guān)數(shù)據(jù)信息
注意事項(xiàng)：從購(gòu)物車(chē)中挑選出商品形成user_order的時(shí)候，此時(shí)user_order和order的具體狀態(tài)state字段要看具體的產(chǎn)品需求由桌，只有真正的生成未支付訂單時(shí)state字段才會(huì)等于1为黎，并且更新shopping_cart信息
此時(shí)再做接口設(shè)計(jì)
- 只要根據(jù)uid就可以查出相應(yīng)的購(gòu)物車(chē)信息
shopping_cart以及根據(jù)order中的state字段(等于0)和shopping_cart_id查出購(gòu)物車(chē)中的商品訂單order用于給前端展示 - 根據(jù)uid可查出生成的總訂單信息
user_order以及根據(jù)order中的user_order_id查出總訂單中對(duì)應(yīng)的子訂單order用于給前端展示
注意：user_order中沒(méi)有具體的商品信息邮丰，只有對(duì)應(yīng)的價(jià)格等信息
接下來(lái)的付款、發(fā)貨铭乾、收貨剪廉、評(píng)價(jià)等對(duì)訂單操作的流程，只要更新對(duì)應(yīng)的狀態(tài)state字段即可
結(jié)合前面的文章一炕檩，或許我們對(duì)于兩種不同的購(gòu)物流程給前端同學(xué)返回的數(shù)據(jù)結(jié)構(gòu)是不一樣的斗蒋，文章一直接購(gòu)買(mǎi)只返回一個(gè)order，而購(gòu)物車(chē)下單卻返回一個(gè)user_order外加多個(gè)order笛质，這樣似乎對(duì)前端開(kāi)發(fā)很不友好泉沾，同樣都是訂單，卻有不同的數(shù)據(jù)結(jié)構(gòu)
綜合考慮妇押，為了追求數(shù)據(jù)結(jié)構(gòu)的一致性跷究，在直接下單的購(gòu)物流程中也要生成user_order，這樣數(shù)據(jù)結(jié)構(gòu)的一致性對(duì)開(kāi)發(fā)來(lái)說(shuō)是很好的一件事情
此時(shí)敲霍，我們要在order和user_order中都各自追加一個(gè)字段
order中追加的字段
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| order_type | num | 訂單類(lèi)型：0=購(gòu)物車(chē)訂單俊马；1=立即購(gòu)買(mǎi)訂單；2=虛擬電商購(gòu)物車(chē)肩杈；3=虛擬電商立即購(gòu)買(mǎi)柴我；199=改簽訂單；200=優(yōu)惠券（主要用于后端邏輯） |
user_order中追加字段
| 字段 | 類(lèi)型 | 說(shuō)明 |
|---|---|---|
| user_order_type | num | 訂單類(lèi)型：0=實(shí)物購(gòu)物車(chē)產(chǎn)生的用戶訂單扩然；1=實(shí)物立即購(gòu)買(mǎi)產(chǎn)生的用戶訂單艘儒；2=虛擬購(gòu)物車(chē)產(chǎn)生的用戶訂單；3=虛擬立即購(gòu)買(mǎi)產(chǎn)生的用戶訂單; 199=改簽訂單夫偶；200=優(yōu)惠券（主要用于后端邏輯） |
其中的虛擬物品購(gòu)買(mǎi)暫時(shí)先不做考慮界睁，值區(qū)分購(gòu)物車(chē)購(gòu)買(mǎi)和直接下單購(gòu)買(mǎi)
另外說(shuō)一下這兩個(gè)字段的其他用處
除了簡(jiǎn)單的區(qū)分訂單類(lèi)型之外，在用戶進(jìn)行下單操作的時(shí)候索守，由于這兩個(gè)字段的存在晕窑，每次用戶下單我們只要update原有的user_order即可抑片，而不用每次都new數(shù)據(jù)
例如卵佛，第一次我們下單某商品，new一個(gè)user_order數(shù)據(jù)敞斋，其中
{
"state": 0,
"user_order_type": 1,
"uid": 123456
}
這樣截汪，只要訂單的state狀態(tài)不變（即訂單未變成待付款訂單），每次客戶下單的時(shí)候植捎，只要根據(jù)state衙解、user_order_type、uid查出相應(yīng)的user_order更新即可焰枢，而不是每次客戶下單都要new一個(gè)新的user_order蚓峦，也就是說(shuō)每個(gè)用戶uid會(huì)只有一個(gè)state等于0的user_order舌剂，只有當(dāng)state狀體變?yōu)?才會(huì)再創(chuàng)建一個(gè)state等于0的新user_order，這樣做似乎更合理（注意：訂單狀態(tài)state由0變成1的操作時(shí)不可逆的）
另外在創(chuàng)建數(shù)據(jù)的時(shí)候暑椰，盡量保證創(chuàng)建的數(shù)據(jù)都有用霍转，而不是創(chuàng)建很多臨時(shí)數(shù)據(jù)，用后在刪除一汽，這樣做風(fēng)險(xiǎn)很大避消。后臺(tái)真正操作刪除數(shù)據(jù)，應(yīng)該是在用戶的手動(dòng)物理刪除操作的時(shí)候召夹。
