本文為以業務邏輯層、數據底層、表現層這三個方面作為思維模型，進行思考并打造了一款從0到1的后臺系統。

作為后端產品經理，刻意練習系統架構設計的能力和對業務充分了解的能力，個人覺得，顯得尤為重要。此文我只關注這兩點，至于原型那些表現層的內容，不在此文范圍。

文中我將通過M V C技術架構（我的思維模型）去思考如何打造一款從0到1的后臺系統。商務咨詢系統，是我負責的一個業務不算特別復雜的系統，以此為例，咱們層層剝離，探尋萬事萬物的本質。

目錄

（1）需求背景

（2）系統價值

（3）系統設計

• 第一步：用例圖
• 第二步：系統流程圖
• 第三步：系統功能清單
• 第四步：系統架構設計
• 第五步：數據庫表結構（對象）
• 第六步：表之間的關聯關系（ER圖）

C：業務邏輯層

（1）需求背景

全國各分公司的商務的同事剛來公司沒多久，對很多業務以及同事都不是很熟悉，出去談業務的時候，經常會遇到很多比較棘手的問題，也會提出很多無規則你根本想不到的問題。

打開釘釘，龐大的組織架構，一堆又一堆的釘釘群，根本不知道找哪些專業人士解答疑惑。

將自己的問題，丟到幾百人的后臺服務支持群，結果很快被其他人的問題給淹沒，不知道找誰提問，不知道在哪里提問，好不容易找到個熱心的同事，結果答非所問，浪費時間。

不知道該在哪里提問？不知道找誰問？沒有人回復？找不到之前的問題解答記錄？公司系統的各種問題，沒地方提出改進建議？

（2）系統價值

• 快速解決商務同事日常業務問題
• 提升后臺支持人員處理問題效率
• 統一提問入口
• 隨時查看問題進度

（3）系統設計

PS：考慮到文中涉及到很多公司內部數據，不得已才打上馬賽克，但不影響此文我想表達的架構設計方法，各位看官見諒。

第一步：用例圖

說明：設計任何一個系統，首先必須搞清楚有哪些參與者，這些參與者都能在系統里做什么，都有什么功能。

第二步：系統流程圖

說明：其次，必須搞清楚這些參與者在系統中是如何操作的，先后順序是怎樣的，有什么判斷情況，有哪些逆向流程等等。而且畫流程圖，建議千萬別一口吃成一個胖子，要循序漸進。

建議按照以下步驟，一點一點從簡入手：

業務流程圖-頁面流程圖-功能流程圖-數據流程圖

2.1 業務流程圖

說明：凡事，先從簡入手，先把當前系統的流程枝干搭建起來，主要流程確定下來，清晰明了地告知所有人：你這個系統在干嘛、要干嘛。其他的枝枝葉葉，先全部去掉，不要影響你的思維，不要打擾你的思路。

2.2 頁面流程圖

說明：主干就像房子的地基，搭好地基之后，就要開始建房子了。具體有哪些頁面、頁面之間如何調整，就要開始想清楚啦。此時，先過濾掉所有判斷條件，所有逆向流程，先跑通所有頁面，先跑通正向流程。

2.3 功能流程圖

說明：地基建好了，毛坯房也建好了，具體房子怎么設計，得開始啦。此時，每往下走一步，盡量多問自己幾個為什么。為什么要這樣做？不這樣做可不可以？

附件1：問題狀態流轉圖

說明：此系統，問題的狀態流轉，比較關鍵，所以用流程圖清晰的表明出來是很有必要的，當前最小MVP做的好不好，關鍵在于問題狀態的流轉，以及問題狀態改變后所有影響情況的考慮。

附件2：問題時效規則設置

說明：問題被人提出來了，什么時候通知給處理人，處理人多久沒處理問題會超時再次提醒，處理人回答完問題，發問人多久不給出評價后，問題自動結束狀態改為已處理等等。問題的時效控制，也是增強系統體驗的一個重要信息，主要用于消息提醒的觸發和問題狀態的改變。

第三步：系統功能清單

說明：當前系統當前版本，總共要做哪些功能，要列出來，告知項目組所有成員，并排好優先級。

第四步：系統架構設計

說明：首先，要想清楚，系統是否要劃分前后臺。一般后臺系統是不需要前臺頁面，直接PC端訪問即可。

但是，此系統是針對商務設計的，那么必須考慮其在外辦公的便利性，部分重要解決其問題的功能，做成wap網頁嵌套在釘釘中或者單獨開發小程序、APP原生頁面就很有必要。載體不重要，重要的是商務使用順暢，簡單方便易操作。

4.1 前臺架構

說明：當前系統，牽涉的外部系統不多，所以架構不復雜。

4.2 后臺架構

說明：從角色權限分配可以看出，當前系統會調用人員組織系統的外部接口，來獲取公司的所有人員以及所屬部門。

M：數據結構層

第五步：數據庫表結構概念設計

說明：依稀記得《java編程思想》中有段話，萬物皆對象。世間萬事萬物，皆為對象，很強大，也很有道理。數據庫表結構，就是對象在程序語言的體現。咱們做系統設計，追蹤到數據底層，就是一個又一個對象，以及對象之間的關系（ER圖）。

其實，將功能拆解為對象并將之表象為數據庫，并不復雜，沒那么玄乎，是有根可循的。舉個例子，咱們通篇都在講發起問題，處理問題。

那問題很明顯就是一個對象，發起和處理，只是他的動作（技術語言叫方法，這里我說的大白話一點），并不能稱之為一個對象。以此類推，數據表結構也就揭開迷霧啦。

PS：數據庫表，對于產品經理，不是必備技能，個人認為會畫的產品，并且時間充裕那就畫一下（畫出來，可以讓你思路更加清晰明了，OMG，原來我的系統就是這幾張表在發揮作用，太牛逼了，技術大哥們），不會并不影響你系統架構的設計。這些是編程小哥哥小姐姐們的看家本領，咱們做產品的了解就好，不強求。我畫出來，是因為，突然心血來潮，就隨便畫了一下。

第六步：表之間的關聯關系（ER圖）

說明：表之間的關聯關系有什么用？可以有一個連帶關系，舉個例子，一個用戶表，一個信息表，一個用戶對應多條信息，當你刪除用戶的時候是不是這個用戶的信息也要被刪除，如果沒有關聯關系的話，你就要在刪除用戶前手工寫條SQL語句去刪除信息表里的對應信息，如果有關聯的話，就不用了，級聯刪除就可以了，只要刪除用戶，這個用戶下面的信息也就沒了。

表之間的關系有四種【一對一、一對多、多對一、多對多】，那么是如何判斷的呢？這里，我只講方法，不講細節。6張表，兩兩相關聯作比較。比如：一個問題對應一個問題分類，一個問題分類對應多個問題，表明問題表與問題分類表是1對多的關聯關系；一個問題對應多個問題狀態，一個問題狀態對應多個問題，表明問題表與問題狀態表是多對多的關聯關系。

再復雜再龐大的業務系統，只要功夫深，經過咱們層層剝離，無非就是一個又一個光禿禿的數據表結構，是不是很好玩，是不是很有趣，不妨使用我本文提到的方法順序，去剝離一個系統試試，你會有驚喜的喲！

V：表現層

表現層，也就是咱們做產品的基本功，將構思好的系統用圖形化的界面表象出來，給項目組所有成員評審，這點不是此文的重點，我不過多闡述。

總結：當前系統，只實現了最小可行性MVP，解決當下核心問題。未來的規劃，是想將本系統打造成商務智能咨詢系統。實現系統能通過問題庫，自動解決80%商務日常提出的問題，20%人工介入。

作者：會飛的豬能上樹，微信公眾號：刻意練習產品經理（ID：kylxpm520）

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

題圖來自Unsplash, 基于CC0協議