Java生鮮電商平台-商品基礎業務架構設計-商品設計
在生鮮電商的商品中心，在電子商務公司一般是后台管理商品的地方。在前端而言，是商家為了展示商品信息給用戶的地方，它是承擔了商品的數據，訂單，營銷活動的數據中心，在后端而言，商品中心則是運營者管理維護商品的地方，因此從商品的上傳到發貨，退貨，整個閉環都離不開商品中心的支撐，因此商品中心的重要性毋庸置疑。本文將從三大模塊去講述商品中心的設計。
一.基本概念
在設計商品中心這一模塊前，我們先弄清楚電商后台常用的一些關鍵詞，有助於我們對業務的理解。
1.SPU：（stanrdard Product Unit，即標准化產品單元），是一組標准化的信息集合，例如：“iphone 8”就是一個SPU。
2.SKU：（Stock Keeping Uint，即庫存量單位），庫存控制的最小可用單位。例如：“iphone8plus256G金色”就是一個SKU。
3.前台類目（分類）：前台類目是為了方便用戶篩選查找商品而設置的功能，運營可根據運營需求靈活調整前台類目，用戶通過前台類目查找相應的商品時，自動從后台類目中檢索相應的商品。
4.后台類目：是為了方便運營者管理商品的庫存，sku，商品規格屬性的一個分類管理功能模塊。后台類目與前台類目相互映射。后台類目一般不輕易變動。
5.屬性：商品屬性是描述商品信息的一組值，通過這類值我們可以建立起對一件商品的基本認知。屬性分為關鍵屬性，銷售屬性，非關鍵屬性。關鍵屬性屬於是指能夠唯一確定產品的屬性，是必填項，例如手機的屏幕尺寸，型號屬於關鍵屬性。銷售屬性是組成SKU的特殊屬性，或稱為“規格屬性”，例如手機的顏色，內存。非關鍵屬性是指除了關鍵屬性，銷售屬性外的其它屬性，如手機的手機接口類型。非關鍵屬性不一定是必填項，可根據運營需求設置。
二.功能架構
在了解完電商平台的基本術語之后，我們則可以根據平台自身的業務需求商品中心了，后台的基本功能大致有四類——增，改，查，刪。因此我們理解該基本功能之后對商品中心的基本功能就有了大致理解。在理解這一點的基礎上，我們需要理解我們平台的管理者和運營者對商品中心的功能需求：我們可以用簡單的用例圖的形式將運營人員的功能畫出來，便於分析。
根據以上用例圖則可以畫出商品中心的信息架構圖：
三.功能設計
在收集完公司的業務需求之后我們就可以開始設計每一項功能：
3.1.發布商品
定義：發布商品是運營者在平台庫中錄入商品數據的基礎功能，發布的商品審核通過后則可以直接在前台展示給消費者，在一些平台商家發布的商品需要經過平台的審核才能在前台顯示，若需要平台審核，則在商品發布之后再商品中心則需要展示商品審核的狀態，以方便運營者知曉商品審核的動態；
需要注意的是:商品的上架和發布需要注意區分，有的平台發布之后則直接展示在前台，用戶直接可以在前台展示，有的平台則需要在發布商品過審后需要點擊上架后才能展示在前端，這里需要根據自身的業務需求去做設計處理。
3.2.商品審核：
定義：商品審核功能是保證商品質量並確保商品合規性的重要措施。審核的對象包含但商家上架的商品，平台自營的商品。審核包含商品性質的合規性，內容的規范性。審核包含商品上傳的前置審核，上架后的審核。前置審核的結果分為通過與未通過兩種，審核未通過需返回不通過原因，便於商家或商品發布者修改。后置審核的結果為兩種，下架和不做處理。后置審核的一般使用場景較少。本模塊着重講商品的前置審核。
商品發布提交后，商品則在平台方的商品中心展示待審核的商品：
商品審核結果有兩種，一種結果是不通過，一種是通過。審核通過時在在售商品列表，審核不通過時在待售商品列表中未通過狀態之列里，審核不通過時后台商品審核人員需要輸入商品審核不通過的原因，以便於商家修改。在商品審核不通過時，在該商品的詳情里需記錄商品的審核記錄。在商品審核結束后平台應及時通知商家運營者，以根據審核結果調整。
3.3.商品下架
定義：商品下架是運營者對在售的商品進行移除的功能，在平台方若下架商家商品則需要對下架說明原因。下架的商品則需要在商品中心有單獨的區域展示。若是平台的商品下架則需對此功能做權限設置，並且在點擊下架時需做二次確認。
3.4.商品修改
定義：商品的修改則在商品列表中添加修改的入口，可以將常用的使用頻次較高的功能在從商品修改頁面中單獨分離出來以保證商品運營人員管理的高效性，例如商品的價格修改，排序修改等等。
3.5.類目管理
定義：運營人員對商品類目進行維護管理的功能，主要包含新增，修改，移動，刪除，查看這五大基礎功能，這里以前台類目管理為例：
原型范例：
需要說明的是：在涉及到類目的刪除，移動時在該類目下沒有商品掛在，否則將會影響前端商品的展示。
從代碼級別來說，也就是刪除類目的時候，需要先判斷類目下面是否存在商品，如果存在就需要提醒用戶，需要先刪除商品，再刪除類目
List<Goods> listGoods=this.goodsService.getGoodsByCatagory(Long catagoryId);
if(listGoods!=null&&listGoods.size()>0)
{
return new JsonResult(”201“，“該類目下存在商品，不能刪除”."");
}
//如果不存在商品。
this.catagoryService.deleteCatagoryId(long catagoryId);
繼續補充：電商商品庫的產品設計與微服務架構
簡單粗暴的講，商品中心是用來管理核心的商品數據。對於使用的維度：從前端來講，是給商品展示、訂單、營銷活動提供商品數據支撐，從后端來講，商品中心給訂單發貨、倉庫管理、供應商管理、采購提供基礎數據支撐。為了更清晰的描述商品中心這項重量級工程，打算寫兩篇文章從上述兩個維度來闡述，本文主要從后端的維度介紹商品中心。
一.商品常用概念介紹
先介紹幾個基本概念：SKU、SPU、屬性、類目。
SKU：stock keeping uint(庫存量單位)，庫存控制的最小可用單位。例如Iphone 7plus 128G 銀色就是一個SKU，倉庫管理、采購進貨、庫存顯示的都是SKU。不同的公司都有自己的SKU編碼規則，如果有自己的倉庫，在商品入庫時一般會打上自己的SKU碼，這樣整一套庫存體系就會自上而下打通，當然還有另一種處理方式，設置自有SKU碼與供應商條碼的對應關系，將訂單轉化為發貨單時，將自有SKU碼轉化為供應商的條碼。對大公司來說，推薦前一種做法，后一種由於供應商編碼規則不同，或者管理規范，在實際操作往往會增加出錯率。
SKU編碼
SPU：standard product unit(標准化產品單元)，是一組標准化信息的集合，例如Iphone 7plus就是一個SPU。SPU與SKU的關系有許多種，可以一對多，一對一，如下圖所示。SPU信息中應該包含SPU屬性、產品圖片、產品描述、產品標簽。SPU和SKU之間是通過規格來鏈接的。SPU(Iphone 7plus)通過顏色、內容關聯到SKU(Iphone 7plus 128G 銀色)。SPU的庫存是由其對應的SKU庫存共同決定的。
SPU與SKU
屬性：分為關鍵屬性、銷售屬性、非關鍵屬性。關鍵屬性是指能夠唯一確定產品的屬性，是必填項。例如手機的品牌、型號屬於關鍵屬性；銷售屬性組成SKU的特殊屬性，或稱為規格屬性，如手機的"顏色"、"內存"；非關鍵屬性指的是除關鍵屬性、銷售屬性外的其他屬性，如手機的手機接口類型，非關鍵屬性不一定是非必填項，有時為了商品信息完整，也會設為必填項。屬性定義對於良好的消費體驗有着至關重要的關系，對搜索、索引、篩選都有至關重要的作用。
類目：分類樹，電商常用的有兩層類目，前台展示類目，后端商品類目。前台類目指的是展示給消費者的類目，會根據季節、銷售策略、活動進行變動；后台類目屬於基礎數據，不可隨意變動，添加SKU時都需要選擇類目，進行綁定。需要注意的是，類目樹的層次不能太深，一般三層或四層，如果太深，不論對於管理還是技術性能來說，都是不利的。前台類目與后台類目可隨意搭配，設置前台類目關聯時，對前台類目樹最深層進行設置，可讓其關聯后台類目任一層，可一對一、一對多。前台類目還可以對應品牌。
京東前台類目
二.商品基礎資料設計
在介紹商品常用概念時，也透露了很多在產品設計時關聯的信息。在添加SKU時，需要選擇品牌、填寫一些屬性，以及關於倉庫管理的基礎數據（長寬高、重量、供應商等）。商品中心基礎資料結構圖主要如下，首先是品類管理，主要包括品牌管理(中英文名、可供品類、產地（跨境電商比較重要）)、屬性管理（針對類目添加相關屬性和屬性值）、類目管理（后端類目樹重中之重，確定時要考慮全面，屬於基礎數據，后續更改比較麻煩。），大致產品框架如圖所示。
商品中心框架圖
在添加SKU時，通過供應商去關聯采購，進而影響倉庫中SKU的庫存。供應商在添加SKU時亦可不選擇，可以在采購系統中添加關聯。通過銷售屬性去關聯SPU與SKU，同一SPU在前台顯示時可以共用同一商品詳情，只是通過規格屬性映射到具體的SKU；針對商品的關鍵屬性和屬性值，可以在商品搜索和篩選時用上，良好的屬性定義對於顧客決策樹的縮短有着至關重要的作用。
SKU使用
還有一個比較特殊的概念：組合SKU，主要是解決出售組合商品的問題，組合SKU的屬性都繼承主SKU。組合SKU的應用場景主要是添加贈品、組合售賣，與前台的商品套餐有所區別。在訂單解析成發貨單時，組合SKU需解析成單一SKU，方便倉庫發貨，更新庫存。
三.復盤
商品中心后端屬於基礎數據，會被許多子系統調用，對於電商公司來說重中之重。商品中心提供接口數據進行倉庫管理、采購管理、庫存管理、訂單管理，可擴展的商品中心結構將給公司業務發展帶來很大益處。
文后擴展，很多電商公司業務定位都是B2B2C，為了擴充SKU，增加用戶量，或者構建平台體系，都會允許第三方來平台管理商品，類似京東、有贊，這類平台的商品結構更加復雜，SKU需要增加所屬商家，商品詳情、屬性值、庫存都需要相互獨立，在SKU、SPU緯度上增加一個商家緯度。這里不做過多擴展，感興趣的朋友可以深入思考。
實物商品
以上文章從后端角度介紹了商品中心用到的一些基礎數據設計，接下來，我們主要從商品前端顯示來說后台設計的那些事兒。用戶平常購物接觸到最多的就是商品顯示頁，商品列表、商品詳情頁的基礎信息都是從商品中心獲取。目前對於商品設計有着成熟的產品方案，電商網站的商品產品結構大同小異，淘寶上的商品以SPU形態顯示，京東上以SKU形態顯示，兩種處理方式各有優劣勢（表達可能不太准確，但認真研究過兩者商品結構應該理解我說的不同點，下文解釋）。 其實我更傾向於淘寶的商品結構，能夠支持更加靈活的商品方案。
京東與淘寶的商品詳情頁
商品信息主要由類目、標題、品牌、商品屬性、規格（京東定義為銷售屬性）、價格、庫存、SKU信息（毛重、長寬高等）、商品圖、商品詳情描述、物流信息等組成。至於經常看到的服務標簽（白條、極速退款）、商品標簽（熱銷）、活動標簽（滿減、優惠券）、價格標簽（拼團價、活動價）、同類商品等都是在商品信息上的包裝層，不在本文的闡述范圍。
1.商品類目、商品基本信息
商品類目分為兩層，基礎數據類目層、前台展示類目層，在添加和管理商品時，都是在基礎數據類目層對商品進行管理（如下圖）。商品屬性、銷售屬性及品牌等很多數據都是在基礎類目上進行管理，所以類目管理屬於較為核心的工作，一定要從長遠角度考慮。
在添加商品時，需選擇對應的類目。前台類目在展示時，有兩種處理方式：
前台類目對應后台類目，可一對一、一對多、多對多，自由組合，動態調整。現在大部分自營電商都是用的這種類型。
前台類目直接對應商品，適合商品較少的小商家，主要是一些電商平台提供給平台上商家的類目服務，添加商品時直接選擇前台展示的類目。
另外，類目一般是分為三層，類目樹不要太深，否則將影響產品效率。
JD商品類目
設置商品信息、副標題（一般介紹產品賣點、促銷），選擇商品對應的品牌。在品牌管理中，有兩種方案：
品牌統一管理，小公司商品豐富度較少時的方案。
品牌關聯類目，商品豐富度高的選擇。
基本信息編輯
2.商品屬性
商品屬性包括屬性名、屬性值，一般都是掛在具體類目子葉下，設置必填和非必填。在設置屬性值時，須保留一定的擴展性，部分允許自定義屬性。商品屬性管理要求強大的類目運營能力，在中小型電商平台一般會提供基礎屬性值，再開放自定義屬性編輯，讓用戶來完善屬性庫數據。
商品搜索能力，除了標題、類目，很大部分依賴於商品屬性，條件篩選的基礎數據也是商品屬性和規格屬性。完善商品屬性對於良好用戶體驗至關重要。
淘寶的商品屬性（男裝>風衣）
3.規格、價格、庫存、SKU信息
在購買商品時，我們會經常選擇規格（銷售屬性），主要包括顏色、尺寸，為了支持多樣化的用戶需求，選擇之后可以編輯規格。規格一對一確定之后，可單獨設置價格、庫存、商家SKU，淘寶上亦可添加條形碼（69碼）。也可以設置統一價、統一庫存。填寫商家SKU主要是為了方便對應到具體的實物，上文亦講過，倉庫和采購管理的都是具體的SKU。
仔細觀察會發現，京東的商品標題是加上具體的規格，在選擇規格時會跳轉SKU，對於落單數據有效率提升，但是對於頁面效率和體驗是不如淘寶的SPU結構的。現在大部分電商都采用的是淘寶的SPU結構，亦是優質選擇。
JD規格、價格、庫存、SKU設置
在淘寶上選擇具體的規格后，會發現商品縮略圖會發生變化，這就需要在管理商品時，針對某規格單獨上傳圖片。這里有個設計很巧妙的地方，只是不同顏色需要上傳對應的商品縮略圖，而尺碼不需要。
淘寶不同顏色上傳具體的縮略圖，京東可上傳多圖
針對商品設置平台價和市場價，主要是為了商品在列表展示商品、未選擇具體規格時展示，相當於商品的均價。毛重、長寬高等數據主要是為了物流而設置的，自建倉庫的自營電商一般在SKU數據層就會錄入這些數據，直接調用。貨號即商品編碼，在商城購物時會掃描的條形碼就是貨號。貨號不等同於SKU編碼，同一商品編碼的商品可能是不同SKU，有着不同的規格，所以不能直接拿貨號來管理SKU。
JD商品信息填寫
4.商品圖、商品詳情描述、物流信息
除了不同規格對應的商品縮略圖，商品圖還包括商品主圖，一般要求圖片質量較高，包括整體圖和細節圖。商品主圖是吸引顧客眼球的必要利器，不論是列表頁，還是活動頁，顧客除了關注價格，主要就是商品主圖，運營上架時需對商品主圖較為慎重。
商品詳情頁現在一般會區分電腦版和手機版，由於兩者的使用場景和設備不同，側重點也不相同。為了更好的展示產品特點，可提供不同的產品詳情模板，亦可支持不同的富文本編輯。
商品詳情描述
選擇運費服務時，要選擇對應的物流模板（包郵、按重量、按件數等），在訂單處理是按照具體的物流模板計算運費。運費模板計算較為多樣復雜，下篇文章詳細描述講解物流運費相關的細節。
商品物流選擇
5.其他商品信息
主要包括售后服務（發票、保修服務、退換貨）、包裝清單等相關說明。
6.上下架管理
設置完商品基本信息之后，設置上下架時間，亦可直接上架發布。和商品相關的活動，一旦商品下架，活動將失效，無法購買。搜索、篩選的商品范圍都是在上架的商品范圍進行。
上下架設置
自營與平台電商的商品區別
在商品管理層面，平台電商提供給平台商戶的商品服務與自營電商自己的商品服務有着很大不同。最大區別在於自營電商比平台電商多SKU管理，庫存和屬性都是基於SKU進行管理，在添加商品時，如果還要重新填寫，就會造成數據冗余。所以一般會共用數據。
總結
這兩篇主要介紹了商品的基礎數據模塊，也是商品的框架，營銷活動等其他部分都是在商品的基礎上進行包裝升級的。由於細節較為繁瑣，很難面面俱到，如果有問題，可留言交流。后面將詳細講解訂單、營銷等后台，若有興趣，可關注我。
學習與交流，請聯系：
聯系QQ：137071249
QQ群：793305035