編輯導讀：產品架構是對商業模式中核心業務場景的抽象，是整個產品的“骨架”，體現了商業模式的運作和實現方式。而對產品架構的設計是通過業務規則來建立產品的內在邏輯，是產品工作中重要的一環。本文作者根據自身工作經驗，分享了一些產品架構設計方法與核心設計原則，希望對你有幫助。

一、什么是產品架構

產品架構是對商業模式中核心業務場景的抽象，體現了商業模式的運作和實現方式，產品架構設計是抽象業務場景，通過業務規則建立產品內在邏輯的過程。

二、以X產品為例介紹產品架構分層

如下圖所示，首先對X產品做一個背景介紹，現在要設計一個電商平臺X，目前只支持自營業務，而且一部分系統已存在（支撐后臺及其服務）。

圖中總共包含4部分： 應用層、服務層、技術架構層、支撐后臺。其中，產品架構主要涉及的是應用層、服務層、支撐后臺，技術架構層是一個簡化的技術架構，添加其目的是為了展示一個全景，讓大家了解一下與產品架構與技術架構的關系。

應用層和服務層體現了“小前臺、大中臺”的戰略思想，是產品架構的核心。當然，并不是說沒有中臺就沒有產品架構，只是這是當前主流的產品架構。如果沒有中臺，服務層就是單純的API，就需要把這部分的服務能力提到應用層里，在此不做介紹。

產品架構與技術架構層的關系：

應用層、服務層、邏輯層、數據層，4層體現了技術上MVC框架的設計思想，是一個邏輯遞進關系，越往底層走越偏向技術實現。

技術架構可以劃分的很細，在此不做詳細說明，主要介紹技術實現原理：應用層通過一次用戶操作獲取數據，然后通過服務層把數據傳輸到邏輯層，邏輯層通過代碼實現的規則對數據層數據進行處理，處理完之后再反向通知到應用層，反饋給用戶，這樣也就實現了一次用戶交互。

三、詳細介紹X產品的產品架構組成

先解釋下“應用層（小前臺）”和“服務層（大中臺）”中“大小”的意思，“小前臺”其實并不是真的小，只是相對中臺小而已，因為中臺包含的服務特別多（如果不理解服務的意思，可以把“服務”改成“能力”），承載的業務也豐富，而不同前臺產品都是有不同定位的，可能一個中臺服務于十幾甚至幾十個產品，所以就是小前臺、大中臺。

那么前臺到底是什么？大家應該對阿里中臺戰略有所了解，如果用阿里的產品矩陣來距離的話，就包含了天貓、淘寶、菜鳥物流、1688等等，但是這部分只是面向前臺用戶的產品，其實還有對應產品的后臺，可能面向各類商家，也可能面向內部管理，這些后臺對中臺來說也都是前臺。說白了，只要是由中臺提供服務的產品或系統，對中臺來說都是它的前臺。

這里存在一個誤區，就是很多人認為中臺在前臺和后臺之間，那就要分清“后臺”到底是名字上有“后臺”，實際是一個由中臺提供服務的前臺，還是產品線上用于支撐該產品的后臺產品。這也就是為什么“平臺后臺”會出現在“小前臺”的原因了。

應用層包含了各種各樣的前臺，不同形態的產品，可能是App端、Web/PC端、H5、小程序，這些不同形態的產品可能面向2C也可能面向2B。

服務層主要包含兩部分：基礎服務（或者叫內部服務）和外部服務。

基礎服務就是要完成X產品需要設計的服務，外部服務就是已經存在于其他產品，可以直接使用的服務（該圖的內外服務不代表實際設計時的劃分，要根據實際情況劃分，數據中臺也不是必須的，在這里占了個坑）。

服務中心提供的基礎服務可以單獨對應用層提供服務，也可以跟外部服務進行組合，形成一個新的服務，對應用層提供服務。

對服務本身的設計不屬于產品設計范疇，但是為了能夠理解產品內在的邏輯，都要對服務有所了解，這是中后臺產品經理的核心能力之一，我會在后面做簡單介紹。

支撐后臺分為兩部分：可直接提供外部服務的后臺系統和支撐X產品數據流轉的后臺系統。

在此解釋兩個概念：

• 服務產品化：當服務層的能力越來越強時，就可以把不同的服務組合，打包成一個新的產品提供給愿意為其買單的用戶。圖中CRM就是服務產品化的結果。
• 產品服務化：當自身的產品做到極致，而且很多其他企業也想要擁有這種能力時，就需要把自身的能力開放出去，然后就出現了“開放平臺”，這是一個典型的開放能力的產品。在開放平臺里，有企業內各種各樣的產品能力，其他企業可以通過對應的API獲取到對應的能力，比如支付、地圖，這就是把支付產品和地圖產品服務化了。

四、產品架構設計方法

X產品的產品架構圖可以簡化成下面這樣（服務中心內的內容體現了其可支撐的業務能力，在畫整體架構圖時可以簡化掉）：

根據上圖來分析產品架構的設計方法（以下為一步步細化的過程）：

1）確定當前產品與其他產品的關系

該產品與哪些前臺產品有關系？是否涉及到建設中臺服務？哪些服務是可以直接用的？哪些是需要新建的？數據是否流轉到其他系統？

也就是把三層涉及的產品關系梳理出來

2）梳理涉及的業務場景與功能模塊

分析產品在各個業務場景下需要什么功能支撐，此處不需要像做前臺產品詳細設計時分析的那么細致。

3）抽象化服務中心的邊界，確認其可提供的業務能力

根據第二步中涉及的實際業務劃分服務中心（也有稱呼叫“子系統”或“服務領域”之類的），并把能提供的核心業務能力填充到服務中心（劃分的原則后面介紹）。

4）將業務能力抽象出業務實體，轉化為支持前臺功能的服務

其實把前三步梳理清楚，整體的產品架構也就出來了，這一步主要是為了詳細設計單個服務中心內部的架構，這一步既體現出了你對業務的理解力，也體現出了你對產品真正的設計能力。

以下以促銷中心為例做分析：

先把各種方式的促銷業務流程畫出來，如下圖所示，可以看出，前五種促銷的整體流程都是一致的，只是促銷的方式和條件不同。而優惠券卻跟促銷不同，而且流程上并不兼容，所以促銷中心抽象出兩個業務實體：促銷活動、優惠券。

有了實體以后，最標準的基礎服務就是對實體的“增刪改查”，以下為促銷中心的產品架構圖（包含了跟其他服務中心的服務關系） ，如下圖所示，什么“滿減、滿贈、立減”已經消失了。

通過這幾步細化下來，也就對服務與服務的關系，服務與產品的關系比較明確了。這樣在做產品設計時，根據實際的業務設計前臺功能就行了，端到端考慮每個產品應該如何設計。

五、因產品增加導致架構變化示例

按上面的思路來分析，現在X要支持其他商家入駐到平臺銷售商品，而且要做一個CRM產品，就形成了如圖所示的X產品體系的產品架構圖：

通過圖中添加的綠色字體部分可以看出，因為業務范圍擴大了，所以補充了對應的商家中心，而且平臺后臺變成了商家后臺，雖然新增了一個CRM，但是服務層并沒有變化。中臺在新的業務到來時在進化（增加了商家中心），而在支撐一個新的產品時中臺卻可以不變，因為在整體架構設計上中臺已經支持了多前臺，除非新的前臺有特殊需求，這就體現了“小前臺、大中臺”的靈活性。

在此，解釋另外一個概念：

SaaS（軟件即服務）： X產品剛開始用戶量很小，但用戶量大增后需要做一個新產品“CRM”用于管理用戶。如果這個CRM是給平臺管理全部2C用戶的產品，就是一個平臺級“CRM”，如果這個CRM是給所有2B客戶單獨管理自己的2C用戶，那么這就是一個“SaaS CRM”。SaaS的關鍵特點是數據隔離，雖然各個商家用的同一個產品，但是不同商家的數據不共享。釘釘、企業微信都是典型的SaaS產品。

六、服務劃分和核心設計原則

最后回顧一下整體架構圖，來看一下服務的劃分和設計原則：

1）服務重在定邊界，遵循高內聚、低耦合原則

高內聚是從服務中心的業務來說的，在一個服務中心內的業務應該是相關性和依賴性很高的；而服務中心之間應該是業務隔離性比較大的，即追求盡可能的低耦合。

2）服務抽象化，盡量通用

抽象是從眾多的事物中抽取出共同的、本質性的特征，而舍棄其非本質的特征的過程。將業務能力轉化成對應的業務實體就是抽象的過程，即對相同或相似的業務能力提取出共性的特征，抽象出可以提供給不同前臺的公共服務，盡量做到服務通用，個性化需求由不同的前臺實現。

3）可擴展性

在服務的設計時不能只滿足當前業務需求，還要考慮服務對未來業務的支撐，這樣可以減少未來對服務的修改。比如說對商品品類層級的設計，理論上來說可以無限層級擴展，但是考慮到前臺的易用性和實際應用，不會設計很多層級也不會只有一層，而三級就能滿足絕大部分業務場景了。所以在設計時也要注意另外一個原則：不過度設計。

4）可復用性

即服務可以多次重復使用，服務的抽象化程度高，可復用性也會越強。在支撐新的業務能力時，優先看是否存在可以復用的服務，如果沒有，再考慮現有服務是否可以通過改造（再次抽象服務或擴展服務能力）達到這一目標，最后才考慮設計新的服務。

5）漸進性建設

漸進性的建設原則是從降低風險和實施難度這個角度出發，推薦小步快跑的方式逐步推進，而不是轟轟烈烈地推翻重來，試錯的成本更低。

本文由 @Zurl 原創發布于人人都是產品經理，未經允許，禁止轉載

題圖來自Unsplash，基于CC0協議。