上篇《後臺產品設計系列：認識後臺》，筆者對後臺（系統）產品做了簡單的介紹，讓大家有一個初步認識。本篇文章，將以視頻產品後臺為例，介紹簡單系統和複雜系統的不同需求設計方式。
產品舉例：如果我們要做一個芒果TV後臺管理系統，簡單的方式和複雜的方式分別怎麼來做呢？
一、簡單系統設計方式——需求驅動設計
針對簡單的後臺產品，我們通常採用需求驅動設計（Request-driven design，以下簡稱RDD）。
1、概念
所謂需求驅動設計，是指我們在設計後臺時，根據上級、運營、市場、客服、前端產品等需求方所提的具體需求，直接進行產品架構、功能設計。這種設計方式簡單快捷，與我們做前端產品思路、方式相同，對於很多做前端產品的同學而言，這種方式是最容易理解和掌握。
2、設計流程
3、流程拆解
（1）明確目標
任何一個產品的萌芽，往往是因為一句話，一個問題，或領導的一個idea，而這些起因，就是我們的產品目標，這些目標有時很模糊，但對於系統產品，這個目標都是很明確的，明確的業務場景下，XX用戶產生的明確需求。例如我們要做芒果TV，分別有APP、web、PC、TV四個端，就需要有一個統一的管理後臺，對前端進行支撐，運營人員能夠對內容進行維護。
（2）需求分析
明確了方向，接下來就需要做需求調研。
第一步：窮舉用戶角色
進行需求調研時，需要先找用戶角色，再找需求。
清晰地列出使用此係統的用戶角色，以用戶角色為劃分維度進行調研。因為後臺產品不同於前端，不同的用戶角色需求差異很大，甚至風馬牛不相及，而每種角色對應的用戶都是這個系統的目標用戶，並不存在所謂的核心用戶和潛在用戶一說，這些用戶都是重要的，都需要滿足他們的需求。例如，使用芒果TV後臺管理系統角色包括運營、產品經理、公司管理者、審核員。
第二步：需求調研
調研方式——深度訪談
與前端產品不同，後臺產品的用戶在現實生活中離我們很近，很容易就能接觸到，這個時候就不要用調查問卷這種大覆蓋面的方式了，一是用戶基數沒有那麼大，二是後臺需求基本不需要做定量分析，無需通過這種方式去挖掘需求。所以直接與用戶交流、訪談是最快速有效的方式；
調研對象——關鍵人
我們的訪談對象，需要儘可能滿足資深、直接使用、有話語權三個條件，因為這種關鍵人所提出的需求會更加全面、具體且有深度，能夠清楚的解釋為什麼要有這個功能，如果沒有會出現什麼後果，還能巴拉巴拉一堆歷史故事，這種用戶就是完美的訪談對象。這些被傷害過的人，知道心痛的滋味；
第三步：建立需求池
根據訪談內容，建立需求池。例如，在對運營、產品經理、公司管理者、審核員訪談後，建立了以下表格
（3）結構設計
將調研後的需求進行初步篩選過濾後，需要根據確定、高優先級的需求，歸納這一期後臺所需實現的功能模塊。
做功能模塊劃分，需要秉持一個重要原則：一個角色，一個模塊，完成一件事。也就是一個具體的角色，能夠在一個功能模塊中完成他想完成的任務。原因主要是以下兩點：
- 降低用戶記憶成本，提升操作體驗。你絕對不想為了做一件事，要在多個模塊跳轉、多個頁面點擊吧，這個看起來對前端產品再正常不過的要求，後臺經常沒有達到；
- 便於權限區分。做系統產品，權限劃分永遠是重點關心的，將一個角色要進行的操作單獨作為一個模塊或模塊下的子欄目，方便做權限設置；
同樣，劃分模塊後進行欄目劃分，然後按照操作流程，從上至下排列，就能得到以下產品結構圖：
至此，簡單系統的產品需求設計階段就告一段落了，後續步驟，且看下回分解。但既然說這種方式只適用於Easy模式，那一定是有原因的。
4、不足
這種設計方式，用開發的行話說，是一種面向過程的設計方式。這種方式有一個專有名詞——貧血模型。
貧血模型有以下幾大致命缺點：
- 創建的對象不準確，直接影響產品和開發對業務的正確把握和擴展；
- 業務邏輯分散，業務難以複用；
- 業務間耦合度高，迭代及維護成本極高；
- 名詞定義不一致，開發與業務出現溝通問題。
二、複雜系統設計方式——領域驅動設計
為了解決上述問題，同時應對複雜的系統產品，就需採用領域驅動設計（Domain-driven design，以下簡稱DDD）模式。
1、概念
領域驅動設計，是指在一個具體的領域中，一種面向對象的設計方式。例如，我們要做一個更大的芒果TV後臺管理系統，以滿足更多角色的更多需求，那麼這個系統就屬於一個具體的領域——視頻娛樂領域。在這個領域中，包含影片、演員、訂單等對象，這些對象就是我們要面向的設計目標，而非直接根據需求做設計。
2、流程
3、流程拆解
在這種方式的流程中，增加了“建立領域模型”和“系統劃分”兩個環節，其他環節與RDD相同，就不再贅述，現針對新增的兩個環節做說明。
（1）建立領域模型
此處的領域模型，是一種簡化後的E-R圖。E-R圖是後臺開發在數據庫設計中通常會用到的一種模型，用來表示實際業務中各個實體及其關聯關係，核心三要素是實體、聯繫、屬性。如下圖中，長方形體現的就是實體，也就是實際業務中的各個概念；橢圓形體現的是實體包含的屬性，類似概念下的各個字段，菱形體現的是實體間的關係。
當在需求設計階段時，並不需要像做數據庫設計那麼複雜的模型，我們需要創建的領域模型，就是要根據實際業務，展現全部的實體及其關聯關係，無需屬性，避免在規劃階段陷入過深的細節。
第一步：與領域專家一起，梳理實體
領域專家，是指對這個領域非常熟悉的人，可以是業務人員、老闆、產品經理等任何角色。這個專家對領域內的各種業務場景和各種業務規則非常清楚，有能力表達出系統該做成什麼樣子，有哪些核心業務關注點。
在本文的例子中，我們梳理的實體包括用戶、影片、欄目、推薦位、演員、導演、訂單、運營活動等，在這些實體概念裡，就是一個個的具體對象，例如演員裡有劉亦菲、劉德華。每個實體要求能用文字精確的、沒有歧義的描述其涵義以及包含的主要信息，同時每個實體定義要完全獨立，概念上不能有交叉或模糊的界線。
第二步：梳理關聯關係
確定了實體，就需要建立實體的聯繫，標識實體間的對應關係。
實體聯繫：
- 直接關聯：實體間直接關聯，在系統中需手動建立聯繫的實體；
- 間接關聯：根據實體圖，能夠通過間接關係找到唯一對應實體。通過間接關聯關係，往往可以通過多條路徑找到同一具體實體，如果出現不同路徑找到不同目標，那就需要重新檢查關聯關係是否正確；
對應關係：
- 1對1（1:1）：1對1關係是指對於實體A與實體B，A中對象至多與B中一個對象有關係；反之，在實體B中的每個對象至多與實體A中一個對象有關係；
- 1對多（1:N）：1對多關係是指實體A與實體B中至少有N(N>0)個對象有關係；並且實體B中每一個對象至多與實體A中一個對象有關係；
- 多對多（M:N）：多對多關係是指實體A中的每一個對象與實體B中至少有M(M>0)個對象有關係，並且實體B中的每一個對象與實體A中的至少N（N>0）個對象有關係。
關聯建立原則：
- 關聯儘量少。實體間的複雜的關聯容易形成實體關係網，這樣對於我們理解和維護單個實體很不利，同時也很難劃分實體與實體之間的邊界；
- 化繁為簡。在建立關聯時，需要挖掘關聯關係的限制條件，如果存在，那麼最好把這個限制條件加到這個關聯上，往往這樣的限制條件能將關聯化繁為簡，即可以將多對多簡化為1對多，或將1對多簡化為1對1；
第三步：走查場景，修改領域模型
- 關聯關係、對應關係是否正確？
- 分析關聯，通過對業務的更深入分析，明確關聯的方向或者去掉一些不需要的關聯；
- 這些實體及關聯關係能否全部覆蓋這些業務場景？
（2）系統劃分
為了解決在方法一中遇到的問題，需要採用微服務的思想，根據實體間的聯繫強弱，以實體為對象，劃分到不同系統中。
將每個系統獨立開（解耦），系統與系統間通過接口調用數據，公共模塊單獨作為一個系統（如此處用戶管理系統），每個系統都有各自的三層結構（詳見上篇）。
三、兩種設計方式總結
介紹完兩種不同的需求設計方式，再來看這兩種方式的聯繫。
1、如何選取
這個圖表示隨著系統複雜程度增加，兩種設計方式開發時間的變化趨勢。可以看出，但產品複雜度低時，RDD的模式會很快捷，這個就非常適合初創型、小型的系統設計，當產品複雜到一定程度時，RDD的開發時間會指數上升，而DDD的模式則始終比較平穩，所以DDD會適合複雜的系統設計。
2、兩種方式中的實體
上篇說到，後臺三層結構中，業務層也叫領域層，其實和領域模型中的領域是一樣的。RDD在數據庫設計時依然需要有E-R圖和實體，但產品經理做需求設計時可以不用考慮（當然有資源這樣做更好），因為對於簡單的後臺產品而言，無需在初期理解的那麼複雜，同時對很多從前端做到後臺的產品而言，不用學習領域模型相關的內容。
那麼在DDD中，對於一個已經對業務非常熟悉的產品經理，可以直接跳過實體，進行系統的微服務設計。但需要注意一個實體在多個系統都存在的情況，這個時候就會導致同一實體的數據，存儲在多個系統中，無論是數據管理還是調用，都會存在問題。所以老司機們還是要劃分清實體，只是不用那麼細緻。
3、兩者關係
寫到這裡，大家其實就會發現，這兩種方式其實是一種包含關係。對於複雜系統而言，需要先採用DDD模式進行前期需求設計及系統劃分，當微服務化後，每個子系統也就變成了簡單系統，也就可以採用RDD的模式了。
閱讀更多 人人都是產品經理 的文章
