去年我們的美妝社區APP， 上線了自有商城。 之後經過多次版本反覆運算， 商城系統的模組已經基本健全， 值此時間分享一些經驗出來， 希望可以共同交流。
主要講講服務端的架構設計以及商品呈現邏輯。 可能對某些PM來說有點難理解， 但是我認為這是設計商城系統的PM必須具備的架構能力， 而且算是比較基礎和底層的部分。
一、商品的基本概念1.1、對使用者而言
一般來說有產品、商品、贈品等概念。
1.2、對資料庫而言
可能只有spu， sku兩個概念， 這是最底層的實體。
SPU（Standard Product Unit）是指標準化產品單元， 是商品資訊聚合的最小單位。 比如iPhone6。 SKU（Stock Keeping Unit）是指庫存量單位， 即庫存進出計量的基本單元。 比如iPhone6國行白色16G。1.3、對功能而言
至少有產品， 標準化商品， 下單商品3個概念。
下單商品。 肯定是一個spu下的sku， 對應著商品編碼。 標準化產品。 對應著spu， 是幾個sku的集合。 產品。 顯示在商城貨架上， 可能是一個spu， 可能是不同spu的組合。注意所謂的sku可能不是單個物理實體， 比如美妝行業經常把2款化妝品用膠布綁在一起作為一個sku， 存入倉庫。
二、商品的存儲
一般而言， B2自營商城選擇租用協力廠商倉庫並對接其系統， 當規模很大的時候才會考慮自建倉庫。
目前我們業務剛剛起步沒多久， 所以只有一個倉庫， 比較簡單。
如果倉庫有多個的時候， 一般會根據“選擇最近倉庫-庫存是否足夠”的原則來處理配貨發貨， 當然可能還涉及到合併包裹的問題。
三、商品的實體關係
以上講了商品架構中需要涉及到的實體， 而他們的屬性和關係決定著資料庫中商品表該如何設計。
可以參考這篇文章《如何用ER圖繪製業務實體模型 》， 瞭解關於實體關係模型的更多知識。
四、商品狀態機
商品的上下架狀態是用來區分商品是否展示給用戶， 以及是否可以成功下單。
贈品是一種特殊的spu， 支持上架並支持用戶購買， 但是建議設為已下架並且是正確價格。
需要說明的是， 售完下架和我下架的， 是為了方便運營客服童鞋操作商城運營系統而設計的， 採用了和淘寶賣家的商品狀態機相似的做法。
可以參考這篇文章《如何繪畫狀態機來描述業務變化》來瞭解其原理。
五、商品的呈現
大部分電商的商品詳情， 呈現邏輯是相似的。
另外京東自營會根據收貨位址和倉庫的位置進行匹配、部分電商會在進入該頁面的時候會選中sku並且自動跳過庫存不足的。
六、總結
我沒有講到類目、商品標籤、商品關鍵屬性、銷售屬性、其他屬性，
不是覺得不重要， 而是我只講了最基礎最底層的設計， 其他的都是根據業務在此基礎上面演變而來。
更多關於商品設計的內容， 可以。