本節(jié)大綱如下：

畫板

從用例圖中我們能看出來商品模塊主要由兩大類功能用例組成：

• 商品分類的相關(guān)功能
• 商品信息的相關(guān)功能

圖片

圖片

本節(jié)我們先來實(shí)現(xiàn)商品分類在商城應(yīng)用中的常用功能。

商品分類在產(chǎn)品中的角色分析

商品分類作為商品的主要導(dǎo)購信息，在手機(jī)應(yīng)用和PC網(wǎng)頁應(yīng)用上的頁面優(yōu)先級并不一樣。手機(jī)因?yàn)榭娠@示內(nèi)容比PC少，所以首頁上顯示的內(nèi)容大部分都是購買率高的推薦分類、爆款單品、以及各種在做的促銷活動。

所以商品分類在App的首頁上并不會全部展示給用戶，而是像下面這樣，在產(chǎn)品中留一個導(dǎo)航入口，進(jìn)入二級頁面在進(jìn)行所有商品分類的展示。

圖片

而在PC網(wǎng)頁上因?yàn)轫撁骘@示區(qū)域的變大，一般在首頁上就有一個商品分類導(dǎo)航，通過多級聯(lián)動來展示所有的商品分類。

圖片

所以服務(wù)端的API返回的分類數(shù)據(jù)的結(jié)構(gòu)，要能適應(yīng)商品分類在手機(jī)App和PC網(wǎng)頁上的展示，一般商品分類都是采用三級分類的結(jié)構(gòu)進(jìn)行組織和維護(hù)（層級如果再多維護(hù)分類的打工人也頭疼），以分類樹的形式返回給客戶端。

商品分類數(shù)據(jù)準(zhǔn)備

商品分類在C端接口中不涉及添加刪除和更新的操作，這些工作統(tǒng)一放在管理后臺由公司的工作人員來維護(hù)。一般管理后臺的用戶跟C端的用戶是隔離開的，登錄也不是用我們之前做的用戶登錄和Token認(rèn)證，更多的是單獨(dú)維護(hù)一套管理員用戶。

現(xiàn)在人員規(guī)模多點(diǎn)的中型公司，基本上管理后臺都是跟自己的員工的統(tǒng)一賬號打通，使用LDAP登錄認(rèn)證，這樣員工離職了工號一禁用，所有的后臺就都不能登錄了，現(xiàn)在使用釘釘和企業(yè)微信的公司都能基于它們自己搭建LDAP服務(wù)。

我們這里就不再費(fèi)力去開發(fā)管理后臺的接口和相關(guān)認(rèn)證了，關(guān)于商品分類數(shù)據(jù)的創(chuàng)建，我們通過一個測試接口把商品分類數(shù)據(jù)初始化好，這里我為大家準(zhǔn)備好了一份商品分類數(shù)據(jù)的JSON文件。

一共有97個分類，基本上電商App上常見的分類都有涵蓋，文件我放在了項(xiàng)目的資源目錄resources中，名稱為category_init_data.json

圖片

resources 這個目錄我們在搭框架的時(shí)候說過是準(zhǔn)備放靜態(tài)資源文件的，之前創(chuàng)建了一直沒用過，今天正好把它用起來。

不過大家別忘了，Go 程序打包的時(shí)候只會打.go文件，這種靜態(tài)資源文件需要我們使用 go embed 功能才能打包到二進(jìn)制文件里去，才能保證把Go項(xiàng)目的運(yùn)行文件放在哪它都能讀取到資源文件。

所以針對resources目錄我們在其中創(chuàng)建一個loader.go

//go:embed *
var f embed.FS

func LoadResourceFile(filePath string) (io.Reader, error) {
 _bytes, err := f.ReadFile(filePath)
 if err != nil {
  return nil, err
 }

 return bytes.NewReader(_bytes), nil
}

在loader.go中我們通過embed *載入當(dāng)前目錄下的所有文件。并提供一個LoadResourceFile方法，讓項(xiàng)目的程序能讀取指定的資源文件

針對我們剛才說的商品分類初始數(shù)據(jù)JSON文件，我們在項(xiàng)目中通過

resources.LoadResourceFile("category_init_data.json")

就能把JSON數(shù)據(jù)加載到內(nèi)存中去。稍后我們會再寫個初始化程序就能把這些數(shù)據(jù)初始化到MySQL的表里。

商品分類按層級分布和展示

商品分類信息有了，接下來就該考慮怎么把他們查出來了。PC 網(wǎng)頁版的購物網(wǎng)站首頁都有一個按層級劃分的分類導(dǎo)航，這個功能需要我們把商品的分類信息按層級組織好后返回給客戶端，接下來我們就來開發(fā)這個功能。

按層級劃分的分類信息該怎么實(shí)現(xiàn)呢？最簡單的實(shí)現(xiàn)方式就是先把所有一級分類查出來，遍歷它們?nèi)缓笤侔迅髯韵聦俚亩壏诸惒槌鰜恚瑫r(shí)二級分類也是這個邏輯：遍歷-每次查下屬的三級分類。

這么做當(dāng)然可以，就是有點(diǎn)費(fèi)數(shù)據(jù)庫，相當(dāng)于一個獲取所有商品分類的接口有可能要查幾十次數(shù)據(jù)庫才能組織好數(shù)據(jù)。當(dāng)然還有另外一種方法：先把分類數(shù)據(jù)查出來，在程序內(nèi)存中靠排序、臨時(shí)變量等方式加工好要返回的數(shù)據(jù)。

那這里我們就采用第二種方法來實(shí)現(xiàn)啦，無論用哪種實(shí)現(xiàn)方式其實(shí)嚴(yán)格意義上來說都沒問題，因?yàn)橄駥蛹壏诸愡@種變更不太頻繁但是結(jié)構(gòu)復(fù)雜的數(shù)據(jù)一般我們會在緩存中緩存一份數(shù)據(jù)，避免每次都讓程序去查數(shù)據(jù)庫。

開始寫邏輯前，我們先在 api/reply/commodity.go 中定義好響應(yīng)的結(jié)構(gòu)

type HierarchicCommodityCategory struct {
 ID            int64                          `json:"id"`
 Level         int                            `json:"level"`
 ParentId      int64                          `json:"parent_id"`
 Name          string                         `json:"name"`
 IconImg       string                         `json:"icon_img"`
 Rank          int                            `json:"rank"`
 SubCategories []*HierarchicCommodityCategory `json:"sub_categories"` // 分類的子分類
}

我們的接口會返回[]*HierarchicCommodityCategory類型的列表，即以一級分類為元素的列表，每個分類的SubCategories中會包含子分類數(shù)據(jù)，這個字段的類型也是[]*HierarchicCommodityCategory，這樣就能滿足我們返回層級分類的要求啦，即使是有四、五級分類用這個結(jié)構(gòu)也沒問題。

一般商品的分類最多也就三級，再多就有點(diǎn)反人類了，維護(hù)起來也不好維護(hù)。

這里說一下命名的問題：Hierarchic 是形容詞意思是按層級劃分的，Hierarchy 是名詞意思是等級、層級，所以在分類層級相關(guān)的技術(shù)文檔里這兩個單詞的出現(xiàn)頻率比較高。

用這個響應(yīng)結(jié)構(gòu)最終我們會構(gòu)造出下面這樣的按層劃分好的分類數(shù)據(jù)，前端拿到這樣數(shù)據(jù)后直接使用即可，不需要做更多邏輯處理。

圖片

好了接下來我們來看生成商品分類層級信息的在領(lǐng)域服務(wù)中的主要邏輯：就能看到按層級劃分好的所有商品分類信息。