產(chǎn)品舉例：如果我們要做一個芒果TV后臺管理系統(tǒng)，簡單的方式和復雜的方式分別怎么來做呢？

一、簡單系統(tǒng)設計方式——需求驅動設計

針對簡單的后臺產(chǎn)品，我們通常采用需求驅動設計（Request-driven design，以下簡稱RDD）。

1、概念

所謂需求驅動設計，是指我們在設計后臺時，根據(jù)上級、運營、市場、客服、前端產(chǎn)品等需求方所提的具體需求，直接進行產(chǎn)品架構、功能設計。這種設計方式簡單快捷，與我們做前端產(chǎn)品思路、方式相同，對于很多做前端產(chǎn)品的同學而言，這種方式是最容易理解和掌握。

2、設計流程

3、流程拆解

（1）明確目標

任何一個產(chǎn)品的萌芽，往往是因為一句話，一個問題，或領導的一個idea，而這些起因，就是我們的產(chǎn)品目標，這些目標有時很模糊，但對于系統(tǒng)產(chǎn)品，這個目標都是很明確的，明確的業(yè)務場景下，XX用戶產(chǎn)生的明確需求。例如我們要做芒果TV，分別有APP、web、PC、TV四個端，就需要有一個統(tǒng)一的管理后臺，對前端進行支撐，運營人員能夠對內(nèi)容進行維護。

（2）需求分析

明確了方向，接下來就需要做需求調(diào)研。

第一步：窮舉用戶角色

進行需求調(diào)研時，需要先找用戶角色，再找需求。

清晰地列出使用此系統(tǒng)的用戶角色，以用戶角色為劃分維度進行調(diào)研。因為后臺產(chǎn)品不同于前端，不同的用戶角色需求差異很大，甚至風馬牛不相及，而每種角色對應的用戶都是這個系統(tǒng)的目標用戶，并不存在所謂的核心用戶和潛在用戶一說，這些用戶都是重要的，都需要滿足他們的需求。例如，使用芒果TV后臺管理系統(tǒng)角色包括運營、產(chǎn)品經(jīng)理、公司管理者、審核員。

第二步：需求調(diào)研

調(diào)研方式——深度訪談

與前端產(chǎn)品不同，后臺產(chǎn)品的用戶在現(xiàn)實生活中離我們很近，很容易就能接觸到，這個時候就不要用調(diào)查問卷這種大覆蓋面的方式了，一是用戶基數(shù)沒有那么大，二是后臺需求基本不需要做定量分析，無需通過這種方式去挖掘需求。所以直接與用戶交流、訪談是最快速有效的方式；

調(diào)研對象——關鍵人

我們的訪談對象，需要盡可能滿足資深、直接使用、有話語權三個條件，因為這種關鍵人所提出的需求會更加全面、具體且有深度，能夠清楚的解釋為什么要有這個功能，如果沒有會出現(xiàn)什么后果，還能巴拉巴拉一堆歷史故事，這種用戶就是完美的訪談對象。這些被傷害過的人，知道心痛的滋味；

第三步：建立需求池

根據(jù)訪談內(nèi)容，建立需求池。例如，在對運營、產(chǎn)品經(jīng)理、公司管理者、審核員訪談后，建立了以下表格

（3）結構設計

將調(diào)研后的需求進行初步篩選過濾后，需要根據(jù)確定、高優(yōu)先級的需求，歸納這一期后臺所需實現(xiàn)的功能模塊。

做功能模塊劃分，需要秉持一個重要原則：一個角色，一個模塊，完成一件事。也就是一個具體的角色，能夠在一個功能模塊中完成他想完成的任務。原因主要是以下兩點：

降低用戶記憶成本，提升操作體驗。你絕對不想為了做一件事，要在多個模塊跳轉、多個頁面點擊吧，這個看起來對前端產(chǎn)品再正常不過的要求，后臺經(jīng)常沒有達到；

便于權限區(qū)分。做系統(tǒng)產(chǎn)品，權限劃分永遠是重點關心的，將一個角色要進行的操作單獨作為一個模塊或模塊下的子欄目，方便做權限設置；

同樣，劃分模塊后進行欄目劃分，然后按照操作流程，從上至下排列，就能得到以下產(chǎn)品結構圖：

至此，簡單系統(tǒng)的產(chǎn)品需求設計階段就告一段落了，后續(xù)步驟，且看下回分解。但既然說這種方式只適用于Easy模式，那一定是有原因的。

4、不足

這種設計方式，用開發(fā)的行話說，是一種面向過程的設計方式。這種方式有一個專有名詞——貧血模型。

貧血模型有以下幾大致命缺點：

創(chuàng)建的對象不準確，直接影響產(chǎn)品和開發(fā)對業(yè)務的正確把握和擴展；

業(yè)務邏輯分散，業(yè)務難以復用；

業(yè)務間耦合度高，迭代及維護成本極高；

名詞定義不一致，開發(fā)與業(yè)務出現(xiàn)溝通問題。

二、復雜系統(tǒng)設計方式——領域驅動設計

為了解決上述問題，同時應對復雜的系統(tǒng)產(chǎn)品，就需采用領域驅動設計（Domain-driven design，以下簡稱DDD）模式。

1、概念

領域驅動設計，是指在一個具體的領域中，一種面向對象的設計方式。例如，我們要做一個更大的芒果TV后臺管理系統(tǒng)，以滿足更多角色的更多需求，那么這個系統(tǒng)就屬于一個具體的領域——視頻娛樂領域。在這個領域中，包含影片、演員、訂單等對象，這些對象就是我們要面向的設計目標，而非直接根據(jù)需求做設計。

2、流程

3、流程拆解

在這種方式的流程中，增加了“建立領域模型”和“系統(tǒng)劃分”兩個環(huán)節(jié)，其他環(huán)節(jié)與RDD相同，就不再贅述，現(xiàn)針對新增的兩個環(huán)節(jié)做說明。

（1）建立領域模型

此處的領域模型，是一種簡化后的E-R圖。E-R圖是后臺開發(fā)在數(shù)據(jù)庫設計中通常會用到的一種模型，用來表示實際業(yè)務中各個實體及其關聯(lián)關系，核心三要素是實體、聯(lián)系、屬性。如下圖中，長方形體現(xiàn)的就是實體，也就是實際業(yè)務中的各個概念；橢圓形體現(xiàn)的是實體包含的屬性，類似概念下的各個字段，菱形體現(xiàn)的是實體間的關系。

當在需求設計階段時，并不需要像做數(shù)據(jù)庫設計那么復雜的模型，我們需要創(chuàng)建的領域模型，就是要根據(jù)實際業(yè)務，展現(xiàn)全部的實體及其關聯(lián)關系，無需屬性，避免在規(guī)劃階段陷入過深的細節(jié)。

第一步：與領域專家一起，梳理實體

領域專家，是指對這個領域非常熟悉的人，可以是業(yè)務人員、老板、產(chǎn)品經(jīng)理等任何角色。這個專家對領域內(nèi)的各種業(yè)務場景和各種業(yè)務規(guī)則非常清楚，有能力表達出系統(tǒng)該做成什么樣子，有哪些核心業(yè)務關注點。

在本文的例子中，我們梳理的實體包括用戶、影片、欄目、推薦位、演員、導演、訂單、運營活動等，在這些實體概念里，就是一個個的具體對象，例如演員里有劉亦菲、劉德華。每個實體要求能用文字精確的、沒有歧義的描述其涵義以及包含的主要信息，同時每個實體定義要完全獨立，概念上不能有交叉或模糊的界線。

第二步：梳理關聯(lián)關系

確定了實體，就需要建立實體的聯(lián)系，標識實體間的對應關系。

實體聯(lián)系：

直接關聯(lián)：實體間直接關聯(lián)，在系統(tǒng)中需手動建立聯(lián)系的實體；

間接關聯(lián)：根據(jù)實體圖，能夠通過間接關系找到唯一對應實體。通過間接關聯(lián)關系，往往可以通過多條路徑找到同一具體實體，如果出現(xiàn)不同路徑找到不同目標，那就需要重新檢查關聯(lián)關系是否正確；

對應關系：

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）個對象有關系。

關聯(lián)建立原則：

關聯(lián)盡量少。實體間的復雜的關聯(lián)容易形成實體關系網(wǎng)，這樣對于我們理解和維護單個實體很不利，同時也很難劃分實體與實體之間的邊界；

化繁為簡。在建立關聯(lián)時，需要挖掘關聯(lián)關系的限制條件，如果存在，那么最好把這個限制條件加到這個關聯(lián)上，往往這樣的限制條件能將關聯(lián)化繁為簡，即可以將多對多簡化為1對多，或將1對多簡化為1對1；

第三步：走查場景，修改領域模型

關聯(lián)關系、對應關系是否正確？

分析關聯(lián)，通過對業(yè)務的更深入分析，明確關聯(lián)的方向或者去掉一些不需要的關聯(lián)；

這些實體及關聯(lián)關系能否全部覆蓋這些業(yè)務場景？

（2）系統(tǒng)劃分

為了解決在方法一中遇到的問題，需要采用微服務的思想，根據(jù)實體間的聯(lián)系強弱，以實體為對象，劃分到不同系統(tǒng)中。

將每個系統(tǒng)獨立開（解耦），系統(tǒng)與系統(tǒng)間通過接口調(diào)用數(shù)據(jù)，公共模塊單獨作為一個系統(tǒng)（如此處用戶管理系統(tǒng)），每個系統(tǒng)都有各自的三層結構（詳見上篇）。

三、兩種設計方式總結

介紹完兩種不同的需求設計方式，再來看這兩種方式的聯(lián)系。

1、如何選取

這個圖表示隨著系統(tǒng)復雜程度增加，兩種設計方式開發(fā)時間的變化趨勢?？梢钥闯觯a(chǎn)品復雜度低時，RDD的模式會很快捷，這個就非常適合初創(chuàng)型、小型的系統(tǒng)設計，當產(chǎn)品復雜到一定程度時，RDD的開發(fā)時間會指數(shù)上升，而DDD的模式則始終比較平穩(wěn)，所以DDD會適合復雜的系統(tǒng)設計。

2、兩種方式中的實體

上篇說到，后臺三層結構中，業(yè)務層也叫領域層，其實和領域模型中的領域是一樣的。RDD在數(shù)據(jù)庫設計時依然需要有E-R圖和實體，但產(chǎn)品經(jīng)理做需求設計時可以不用考慮（當然有資源這樣做更好），因為對于簡單的后臺產(chǎn)品而言，無需在初期理解的那么復雜，同時對很多從前端做到后臺的產(chǎn)品而言，不用學習領域模型相關的內(nèi)容。

那么在DDD中，對于一個已經(jīng)對業(yè)務非常熟悉的產(chǎn)品經(jīng)理，可以直接跳過實體，進行系統(tǒng)的微服務設計。但需要注意一個實體在多個系統(tǒng)都存在的情況，這個時候就會導致同一實體的數(shù)據(jù)，存儲在多個系統(tǒng)中，無論是數(shù)據(jù)管理還是調(diào)用，都會存在問題。所以老司機們還是要劃分清實體，只是不用那么細致。

3、兩者關系

寫到這里，大家其實就會發(fā)現(xiàn)，這兩種方式其實是一種包含關系。對于復雜系統(tǒng)而言，需要先采用DDD模式進行前期需求設計及系統(tǒng)劃分，當微服務化后，每個子系統(tǒng)也就變成了簡單系統(tǒng)，也就可以采用RDD的模式了。