電商產品體系非常復雜，很值得深入研究，我準備集中一段時間對這個產品體系進行設計拆解。商品中心的拆解是此系列的第一篇。

電商產品架構

說到電商，作為消費者可能有比較直觀的體感，在網上商場里面的購物流程大概如下：

瀏覽商品—>選購商品—>支付下單—>坐等物流送貨上門—>評價商品—>訂單完成。

這里面每一個環節都涉及到1個或多個系統在背后運行支撐，非常復雜。

如果你在淘寶開過店，就會知道淘寶后臺同樣存在著一套非常復雜的商家支撐系統，支持著商品的上架發布、庫存管理、促銷活動管理、物流管理、訂單管理、評價管理等一系列后臺操作，這些操作都是相互獨立又互相銜接的獨立系統在支撐。

從消費者、商家的角度來進行粗獷的感知，我們就會知道電商體系的復雜度可想而知，根據以上的場景，我們可以粗略地畫出電商的產品架構：

商品的幾個概念

電商產品形態的目標，本質上其實就是賣貨。為了提升賣貨效率，電商產品主要圍繞著3方面的工作展開：

1. 信息流：提升信息流動的效率，讓商戶方便的發布商品信息，用戶方便的尋找商品信息。
2. 資金流：提升資金流動的效率，讓用戶方便的下單支付，商戶更方便的結算資金。
3. 物流: 提升實體商品流動的效率，讓商戶更快的從商家流動到用戶手中。

商品中心 是電商產品的信息化基礎，商品信息是信息流的重中之重，如何讓商戶將商品信息格式化，商戶可以方便的進行發布管理，用戶可以便捷搜索瀏覽，是商品信息化的核心。

電商系統經過了這么多年的發展，已經形成了一套比較成熟的商品信息模型。在進行系統設計拆解之前，有必要對一些概念進行講解。

SPU & SKU

概念簡寫先來看下定義：

SPU：

標準化產品單元，是商品信息聚合的最小單位。是一組可復用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。通俗點講，屬性值、特性相同的商品就可以稱為一個SPU。

SKU:

庫存量單位，即庫存進出計量的單位，可以是以件、盒、托盤等為單位。SKU是物理上不可分割的最小存貨單元，在使用時要根據不同業態，不同管理模式來處理。

概念看完以后，似懂非懂。

看個例子吧。

iPhone X —— SPU iPhone X 土豪金色 128g —— SKU

iPhone X就是一個SPU，它集合了“電子產品-手機-蘋果手機-iPhone X” 下的所有商品屬性信息。只要說是iPhone X，人們就知道是這個型號的手機。

大家想想平時我們討論手機的場景，其實說的都是SPU，比如說：

A：聽說你買了新的手機，是什么？ B：華為Pro30。你現在用的是什么？ A：我還在用iPhone X 呢。 你看，這個場景中說的都是SPU。

SPU是定位到產品的概念，但它和產品細節無關。但實際上，我們在購買商品的時候，單憑SPU是不夠的，還需要更多的信息來精確到可購買單元。

在Apple Store購買iPhone時，我們可以說：“我想買iPhone X。”

接著導購一定會問你：你要的是什么顏色的？內存多少？

所以，在實際的交易行為中，必須要有一個最小購買單位來對應一件商品——這就是SKU，在商家端也稱庫存單位。

屬性

從SPU&SKU的概念可知，其實他們之間是存在聯系的。他們的關系可以如圖所示：

它們之間的關系可以用一句話總結：

SPU 疊加上銷售屬性后，就得到了SKU。

舉個例子，

iPhone X是SKU, 疊加了土豪金(顏色屬性)、128G（容量屬性）以后，它就變成了SPU。

后臺類目 & 前臺類目

08年的時候，電商產品的類目劃分還并沒有區分前后臺，但是商品類目的設計革新已經迫在眉睫：

1、商品庫越來越龐大，對應的類目級別越來越深，商家發布商品，用戶查看商品的難度越來越大。

2、電商商城平臺的營銷活動日益增多，商品類目的變化需求極大，但是類目維護成本高昂

淘寶的產品經理在去逛沃爾瑪超市的過程中得到了靈感，他發現傳統超市的分類邏輯可以很好的被電商產品借鑒：

大超市里的商品，在貨架上的陳列方式都是經常變來變去的，隨著季節、特殊節日、銷售狀況等因素的變化，商品的陳列方式也會經常做出調整。

但大超市還有一個地方是倉庫，倉庫里的商品擺放是相對固定的，食品就在食品區，洗護就在洗護區。所以說，超市里的商品其實是放在兩個地方——后臺倉庫和前臺貨架，使用的分類方法也是截然不同的。

從這里他受到啟發，想出了“前臺類目+后臺類目”的設計方案——把一個產品一分為二，一個滿足買家，一個滿足賣家，也就是：

賣家通過后臺類目發布商品，買家通過前臺類目選購商品。

原來的類目變成了后臺類目樹，另外再建一個前臺類目樹，然后把前臺類目樹的葉子類目去和后臺類目通過映射關系關聯起來。任何一個前臺類目的葉子類目，都可以對應任何一個或多個后臺類目，且不一定是后臺葉子類目。

現在，類目設計的前后臺分離已經成為電商產品的標配。

附上天貓商城和小米商城的前臺類目：

設計拆解

系統設計概覽

任何脫離了業務場景的設計，都是耍流氓。商品的模型從直覺上來可以很簡單，就是對商品信息進行維護就可以了。但是從上文中可知，信息維護僅僅完成了第一步，如何讓信息流動更高效，如何對千萬級甚至億級的商品庫進行快速維護、高效檢索，對商品信息分類的需求是自然發生的。基于上文中商品的核心概念，我們可以得到商品中心的系統概覽圖：

模型設計

業務場景清晰了，模型設計是水到渠成的事情。從模型關系圖可知，商品中心的核心模型包括

• SPU
• SKU
• 類目
• 屬性定義 & 屬性值
• 品牌

在這里，我直接放出模型設計：

上圖中模型設計僅包含后臺核心模型設計（抓大放小），前臺類目的設計比較靈活多變，可以直接復用后臺類目的設計思路，也可以新起一套，按照商城前端UI呈現的需求進行設計。附上完整的代碼定義：

// 品牌表 brand
{
  "id": "主鍵ID",
  "name": "品牌名字",
  "icon": "品牌圖標",
  "desc": "描述",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }
// 類目表（后臺）  back_category
{
  "id": "主鍵ID",
  "pid": "父ID",
  "name": "類目名字",
  "desc": "描述",
  "leaf": "是否為葉子節點，1-是，0-否",
  "level": "層級",
  "path": "類目路徑",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }// 類目表（前臺）  front_category , 一般兩級就夠了
{
  "id": "主鍵ID",
  "pid": "父ID",
  "name": "類目名字",
  "desc": "描述",
  "leaf": "是否為葉子節點，1-是，0-否",
  "level": "層級",
  "path": "類目路徑",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }// 屬性定義表 attr
{
  "id": "主鍵ID",
  "name": "屬性名字",
  "desc": "屬性描述",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }
// 屬性值表 attr_val
{
  "id": "主鍵ID",
  "attrId": "屬性id",
  "valName": "屬性值名稱（用于展示）",
  "val": "屬性值（用于存儲）",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }
//標準產品單元 spu
{
  "id": "主鍵ID",
  "name": "spu名字",
  "desc": "spu描述",
  "brandId": "歸屬品牌",
  "categoryId": "歸屬類目",
  "unit": "單位",
  "url": "產品介紹鏈接",
  "price": "價格",
  "showPrice": "展示價格",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }
//庫存單元 sku
{
  "id": "主鍵ID",
  "spuId": "SPU ID",
  "name": "名字",
  "desc": "描述",
  "brandId": "歸屬品牌",
  "categoryId": "歸屬類目",
  "unit": "單位",
  "url": "產品介紹鏈接",
  "price": "價格",
  "showPrice": "展示價格",
  "attrs": "屬性值集合[{attrId:'', attrName:'', val:'', valName:''},{attrId:'', attrName:'', val:'', valName:''}]",
  "status": "狀態：-1-已刪除,0-禁用，1-正常," }// 關聯關系（后臺） sku_map
{
  "id": "主鍵ID",
  "spuId": "SPU ID",
  "skuId": "SKU ID",
  "categoryId": "類目ID（葉子類目）",
  "categoryName": "類目名稱",
  "attrId": "屬性ID",
  "attrName": "屬性名稱",
  "attrVal":"屬性值",
  "attrName": "屬性值名稱" }// 關聯關系（前臺） sku_front_map
{
  "id": "主鍵ID",
  "spuId": "SPU ID",
  "skuId": "SKU ID",
  "frontCategoryId": "類目ID（葉子類目）",
  "categoryName": "類目名稱",
  "attrId": "屬性ID",
  "attrName": "屬性名稱",
  "attrVal": "屬性值" }

接口設計

主要從前端商城的需求出發，重點考慮下前端在獲取商品數據時的接口需求。

拉取類目

此接口主要在商城首頁的商品類目展示區進行數據支撐，具體如圖：

前臺類目的靈活性就體現出來了，不同的前端，可能類目的設計是不一樣的，這里可以做一下分類：

• PC端，視覺空間大，前臺類目可以承載一定的復雜度，天貓采用的是3層結構。
• APP端，視覺空間收窄，前臺類目應該簡單點，層級不宜過多。
• 小程序端，交互效果相對于APP而言，進一步受制，不應該堆太多的信息元素，可以稍微做幾個重點運營類目。

在參數設計上，可以根據端來進行進行不同的數據拉取。

請求參數：

{
 "PC|H5|APP" }

響應參數：

// 類目接口
{
  "code": 10001,
  "msg": "success",
  "data": [
    {
      "id": "類目id,int",
      "name": "類目名,string",
      "icon": "類目icon，string",
      level2: [
        {
          "id": "類目id,int",
          "name": "類目名,string",
          "level3": [
            {
              "id": "類目id,int",
              "name": "類目名,string",
              "url": "類目指向的URL"             }
          ]
        }
      ]
    }
  ]
}

根據類目拉取商品列表

當用戶點擊最后一級類目，網頁會跳轉到商品列表，此時系統需要根據類目ID拉取出商品清單。

輸入參數：

{
 18774 }

輸出參數：

// 根據類目拉取商品信息
{
  "code": 10001,
  "msg": "success",
  "data": {
    "brand_list": [
      {
        "id": "品牌id，string",
        "name": "品牌名,string",
        "icon": "品牌url,string"       }
    ],
    "spu_list": [
      {
        "id": "商品id，long",
        "name": "商品名，string",
        "desc": "商品描述，string",
        "price": "商品價格",
        "url": "商品鏈接，string"       }
    ]
  }
}

根據商品spu_id拉取商品詳情

當用戶對某個商品有購買意向，會點擊商品查看詳情，這時候會進入到商品詳情頁，如圖:

這時候需要系統根據商品spu_id拉取商品詳情，特別是商品屬性數據。

輸入參數：

{
 18774 }

輸出參數：

// 根據商品spuid 拉取商品詳情
{
  "code": 10001,
  "msg": "success",
  "data": {
    "brand": {},// 品牌
    "spu": {},  // 商品描述
    "category": [  // 商品屬性
      {
        "id": "",
        "name": "",
        "desc": "",
        "status": ""       }
    ]
  }
}

到此為止，商品中心的核心模型和關鍵流程都做了設計拆解，當然，以上內容僅僅只能作為商品管理模塊在系統中存在，商戶中心涵蓋的范圍大得多，商品的信息模型確定以后，商品搜索、商品推薦 等系統服務跟上了，才能讓用戶達成一次較好的購物下單體驗。這些內容比較獨立，以后單獨作為主題展開講解。本文側重于商品的信息模型的構建和核心流程節點中的服務接口的拆解，算是電商產品拆解的第一步吧。

本文標題：電商體系商品中心設計拆解
分享鏈接：http://www.js-pz168.com/news2/103602.html

成都網站建設公司_創新互聯，為您提供靜態網站、全網營銷推廣、自適應網站、商城網站、品牌網站設計、網站維護

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯