產品經理都希望能做出一個可復用性強、靈活性好的B端系統出來。那么，模塊化設計就是其中一個很好的方法。

一、為什么要模塊化設計？

希望減少重復性造輪子的可能，抽離出共通性、形成標準化，最終達到減少人力物力的大量浪費，提高業績的同時還減少了成本開支，何樂而不為？

最近鼓吹得如日中天的中臺概念、流行了許久的敏捷開發，無不都是為了此目的。

當前較為普遍的兩種方法:接口式開發、模塊化設計。

1. 接口式開發：開發角度

寫代碼的同學都知道，代碼要講究可復用性、靈活性。前端開發與后端開發，采用接口式方法來進行信息之間的交互。

案例：我要登錄淘寶網站。

上下游系統之間，跨系統之間，也大多采用接口式方法進行信息傳遞。

此文，咱們簡單聊聊B端系統模塊化設計的好處。

2. 模塊化設計：產品設計角度

模塊化設計，專業術語講是為了我們做的產品，將來靈活性強、擴展性好。不需要開發修改代碼，就可以實現部分新的業務邏輯。

通俗點講，就是堆積木。我們可以將任意小方塊，任意拼湊成我們想要的形狀，從而達到目的。

不同的系統，不同的業務，要根據實際情況分析，這里我以電商系統為例，總結了些許模塊化設計經驗，分享一二。不到之處，還請大佬們批評指正。

二、適不適合模塊化設計？

1. 搞清楚事務本質

首先，一定要搞清楚為什么要去模塊化設計，千萬不要為了模塊化而模塊化，這個是很大的忌諱。模塊化設計，很多時候短期是看不到任何效果的，而且讓系統變得更麻煩。

以添加商品為例：要新建一個商品，必不可少的有商品基本信息、商品類目、商品屬性信息等等。

如果想簡單點設計：

1. 點擊添加商品按鈕，進入添加商品頁面；
2. 在固定表單中，填寫商品所有信息；
3. 點擊保存按鈕。

添加商品，本就不是很復雜的事，此簡單的方案不是不可行。只是不利于系統的可擴展性和靈活性。

為什么？在固定的表單中填寫商品所有信息，你就能保證所有的商品都是一樣的業務邏輯，一樣的商品信息嗎？根本保證不了，那么一旦做成固定模板，系統后期就要不斷的根據新的業務邏輯和商品去不斷的改代碼來實現業務方的需求。

那么，有沒有更好的方案？模塊化設計。

回到問題本質：想成功添加一個商品到商品庫。

方案：將商品信息打散，將其拆分為三大類信息組合：商品共性信息（所有的商品都有的屬性）、商品類目、動態屬性（區分商品唯一性的屬性）。

2. 理清父子關聯關系

既然要模塊化，那么肯定就會出現一層又一層的父子關聯關系。

說明：要想成功添加A商品，必須關聯某個A商品類目。A商品類目必須關聯某個A模板，A模板必須關聯對應屬性。

屬性管理：管理了商品的所有類別的屬性信息，一定要做好分類。比如：關鍵屬性、規格屬性、非關鍵屬性等等。

模板管理：不同的商品，可能由不同的屬性構成。那么我將屬性形成一個又一個模板，就可以靈活的去滿足各種類別的商品。

商品類目：商品的分類管理。所有的商品，肯定有自己的分類，也就是商品類目。同一類商品歸為一類，便于商品的維護和管理。

商品管理：所有商品的管理?，F在要添加一個商品，通過模板化設計，就變得非常靈活。要想添加商品：

1. 點擊添加按鈕；
2. 選擇A商品類目；
3. 填寫A類目關聯的模板A中對應的屬性信息；
4. 保存。

模板設計的好處就是，我可以隨時更換關聯關系，也可以隨時在下一層關聯關系中做任何CRUD操作卻不影響當前層級新的數據。

三、如何模塊化設計B端系統？

記住我一句萬變不離其宗的話：

所有的系統設計無非就是對數據庫中各種表格的CRUD（增刪改查）。

別把后臺系統設計想的那么玄乎，沒有那么復雜。咱之所以覺得復雜，是因為咱還不夠熟悉業務，不清楚正向逆向各種流程，并不是系統設計難。

1. 功能結構圖：有哪些功能、頁面、按鈕

說明：

1. 下圖是我認真畫的真實數據，認真觀察后發現沒有？哪個版塊的管理離開的了CRUD？先講頁面的根（CRUD）想好，什么批量克隆、啟用、停用無非添磚加瓦而已；
2. 功能結構圖也就是功能列表，只是功能列表會描述的更細，而結構圖只是列出大的框架，方便參閱，沒你想象的那么復雜；
3. 雖不復雜，但每一層的關聯關系可別忘記加上，這可是咱這篇模塊化設計的核心。

2. 信息結構圖：有哪些對象和字段

信息結構圖：將你看到的頁面信息，抽象處理到一個對象的維度，然后把同一個對象的信息放在一起。

咱們產品人畫的信息結構圖，不需要與開發同學設計的數據庫表結構一模一樣，按你的理解將其以單個對象維度抽離出來即可。

有沒有覺得設計信息結構圖很難，根本無從下手，不知所措？根本原因在哪？在于咱們腦海中沒有面向對象的概念和對數據庫表結構的理解。

什么叫對象？萬事萬物，皆為對象。你，我，鼠標，鍵盤，電腦都是對象。

對象：指具體的某一個事物，即在現實生活中能夠看得見摸得著的事物。在面向對象程序設計中，對象所指的是計算機系統中的某一個成分。

在面向對象程序設計中，對象包含兩個含義，其中一個是數據，另外一個是動作。對象則是數據和動作的結合體。對象不僅能夠進行操作，同時還能夠及時記錄下操作結果。方法是指對象能夠進行的操作，方法同時還有另外一個名稱，叫做函數。方法是類中的定義函數，其具體的作用就是對對象進行描述操作。

對象解析：對象由屬性和方法構成。private開頭的全是對象應有的屬性，也就是咱們看到的信息架構圖中，員工對應的信息。至于方法，咱們產品經理不需要關注，知道有就好。

表結構：表名+字段。詳情可以看我另一篇文章的文末，這里不再說了哈！《后臺系統架構設計-商務咨詢系統》

表解析：員工信息表用來儲存員工的基本信息。一般由表明+字段構成，我們產品人不需要去關注數據類型，是否主鍵這些信息。

3. 原型圖：系統長什么樣，有哪些規則和交互效果

PS：原型只是案例展示，并不是真實功能，有很多按鈕和規則，都沒有寫入，僅供參考。

如果你真的涉及想用模塊化設計，需要找人交流的時候，記得找我喲！

屬性管理：

說明：屬性分類與屬性分組是不同概念。屬性分組是將一類屬性進行分組，是站在業務維度劃分。屬性分類，是站在產品設計維度分析。

模板管理：

1. 模板有點類似屬性分組，將一組又一組屬性構建成一個又一個模板。
2. 模板一定要關聯屬性，否則毫無意義。

商品類目：

1. 商品類目，一定要去關聯設置好的不同業務的模板；
2. 一個商品類目可以關聯多個模板。

商品管理：

1. 添加商品，也就變得簡單方便。直接選擇商品類目后，填寫當前業務的商品模板中的屬性信息即可；
2. 如果業務有變動，商品屬性的增刪改查變得游刃有余，不會影響舊的在售商品。隨時更換隨時增加新的判斷，都可以，想怎么玩就怎么玩兒。

總結

所有的系統設計無非就是對數據庫中各種表格的CRUD（增刪改查）。

作者：會飛的豬，微信公眾號：刻意練習產品思維（ID：kylxpm520）

本文由 @會飛的豬 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議