我們常常會看到“產品架構”這個詞，甚至能看到有些公司專門有一個叫做“產品架構師”的崗位。
說起架構，很多人會覺得很虛，那麼到底什麼是產品架構呢？
我們知道開發有專門的一個崗位叫技術架構師。推己及人，我們先看下技術架構師是幹嘛的？
架構師能對線上業務進行模塊劃分，系統拆分重構，並做好相關高可用的措施，以保證系統的穩定，安全、高效地運行。簡單來說這是一個既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導任務。
先來看下技術架構師的幾個核心關鍵字：
權衡與平衡，抽象、建模與設計，預見性和前瞻性，簡化之美，模式與重用，質量、效率與資源，敏捷、迭代與演進，前構與重構 。
本質上，技術架構的關鍵字同樣適用於產品架構。
技術架構中有一句比較流行的話：一切脫離業務的架構都是耍流氓。產品更是如此。
一、什麼是產品架構？
1、先來看看“人”的構成
（1）從原子水平60多種重要的，如：氧佔約65%、碳佔約18%、氫佔約10%、氮佔約3%，(這四個元素約佔人體96%)。其他元素較少，但也很重要。
（2）、從分子水平上說，水約佔人體約60%，碳水化合物和脂肪占人體約14%，蛋白質占人體約17%。其它如維生素、礦物質、纖維素等。這些是人體的七種營養素。這七種營養素在人體中每一個都扮有非常重要的作用，不可缺少，也不可過多。
（3）在細胞水平分析，人體由細胞、細胞外液及細胞外固體組成。細胞是組成人體的基本單位。
（4）在組織水平分析，人體是由四大組織組成，即上皮組織、結締組織、肌組織和神經組織。
（5）在器官水平分析，多種組織以不同的編排形成器官。人體內有很多器官，如胃、肺、心、腎、脾、胰、肝、膀胱、尿道、子宮等。
（6）在系統水平看，共有9大系統。如消化系統、呼吸系統、脈管系統、內分泌系統、神經系統等等。
我們以消化系統做一個比喻，就很清楚了。先來看下消化系統的示意圖：
我們會發現人體消化系統：
（1）由很多器官組成：由消化道和消化腺兩大部分組成。
（2）能形成一套自發的運作流程：食物進入口腔、咽、食道、胃、小腸（十二指腸、空腸、迴腸）和大腸（盲腸、闌尾、結腸、直腸、肛門），最後排出肛門，流程結束。其中消化腺分佈在消化道管壁附近，並將消化液排入消化管內幫助消化食物。
（3）有必要的功能作用：食物的消化和吸收，供機體所需的物質和能量
2、B端業務體系的構成
“人體的消化系統”非常像“B端的業務體系”，比如一個患者來診所看病：
客戶需要先在網上預約，然後在約定時間到診所登記、看診、付費、取藥，最後離開診所。
整個業務流程由很多”器官”組成：“軟性器官”比如預約、登記、看診、付費、取藥等模塊，“硬性器官”比如醫生、護士、藥師，以及對應的藥品、材料、叫號硬件、打印機等等。
這些軟性和硬性的“器官”在整個流程體系中相互協同發揮著不同作用，才能夠讓患者在流程中順利的往後推進，直至到達流程的終點。這套業務體系發揮的作用就是有序的讓患者得到診療。
說完了人的消化系統，再反觀B端業務，我們會發現很多相似之處：
（1）消化系統——業務流程體系
（2）組織——底層基礎模塊
（3）器官——一級業務模塊
（4）細胞——二級業務模塊
（5）分子——頁內tab（三級業務模塊）
（6）原子——字段
這裡出現的“底層基礎模塊”、“一級業務模塊”、“二級業務模塊”。。等本質上就是對業務的分層。
1、定義層級
一般來說B端產品的分層基本就是按照上述（2）-（6）的維度進行劃分的，可視業務複雜程度適當增加或減少層級。
2、完成分層
將同一平臺下、同一職能下、同一角色下具有高度關聯的子模塊分到同一層母模塊中，這就需要你作出判斷哪些模塊是業務相似度和關聯度都非常高的。
事實上（2）-（6）構成了業務的結構，每個維度模塊們的任意一個模塊都是結構中的節點，他們之間相互獨立，但又相互關聯、相互影響。
類似計算機網絡的結構：
所以我們看到：B端業務的核心在於業務流程+結構，且業務塑造的結構是為業務流程而服務，什麼樣的業務流程決定什麼樣的業務結構。
3、B端產品架構的構成
產品架構就是對業務的結構化抽象！
根據業務體系的分析，我們看到其實TO B產品最後就是要抽象出準確的流程+結構。
我們常常說一個功能，或者一個業務場景的解決方案，本質其實就是一個小系統。
在這個小系統中，上面那些“底層基礎模塊”、“一二三級業務模塊”、“字段”等各種節點支撐了這套業務流程，從而使得這個功能（解決方案）能夠形成閉環，並順利的運轉起來。
而眾多功能／解決方案又構成了一個產品整體，就像這些眾多的相互獨立、相互作用、相互依賴的小系統組成了一個大系統。
再強調下：大家要記住TO B業務中，流程是核心，結構都是圍繞業務流程進行劃分和設計的。所以流程的優先級是大於結構的。
二、如何繪製業務流程圖？
一款產品的主要核心業務流程的脈絡一定是非常清晰的。
比如這是一款自助開票軟件，那麼核心流程一定是用戶掃碼自助填寫開票信息，並由系統完成開票，併發送到用戶手機／郵箱。
比如這是一個電商平臺，那麼核心流程一定是選購商品，添加購物車，下單完成支付。
當然B端複雜的業務場景往往會有多條主業務流程，並且附帶了很多分支流程。
我們在畫流程的時候，首先要定義橫縱向維度，其次就是劃分模塊。
一般來說，流程圖的縱向維度可以做成職能部門／角色／平臺層
流程的橫向維度可以進行平臺層／模塊層的劃分
以下圖“拼團功能”為例，橫向是平臺層，縱向是模塊層，這是一個跨平臺跨模塊的產品需求。可以看到在這個業務流中，一級模塊劃分出了營銷、商品、訂單、統計模塊。
本質上劃分模塊就是對業務流的解耦。
三、模塊劃分的基本原則？
根據上述流程構建的一個非常簡單的產品結構圖：
這個結構圖略去了很多，只是想做個示意
這其中我們看到劃分出來了“商品”、“活動”、‘訂單“、”統計“，加上“商家管理”、“消息推送模塊”共6個模塊。
那麼在劃分模塊的時候我們要關注哪些原則呢？
1、關注低耦合
1）什麼叫解耦？
藕斷絲連，這個詞語非常形象，業務體系就像一個藕，業務內部的模塊之間的相互關係就像藕絲一樣錯綜複雜，又互相依賴、聯繫緊密（耦合），解耦就是把藕折斷，分成獨立的兩部分。
本質上它是把場景不同、業務屬性不同的模塊進行拆分，歸為不同的兩類，但是因為兩者都為業務流程服務，這其中難免會有相互協同的地方，於是就會有絲連的情況，這種絲連體現在流程中。
2）解耦的作用？
解耦能夠讓場景更聚焦，讓功能模塊更聚焦垂直業務。比如積分模塊，凡是跟積分相關的一切業務需求，如無特殊情況，都可以被歸集到積分模塊中。對於需要用到積分的其他業務，則可以通過開放一些標準接口供其他業務調用。
最忌諱的是把另一個業務（隨便舉個例子比如活動模塊：抽獎活動，抽中就送積分）和積分模塊聚合在一起，這會導致，任何一個模塊要做修改和迭代時，都會最大程度的影響另一個模塊，導致無論產品還是技術的迭代成本都異常之高。
2、關注角色場景
對於不同職能／角色不同的使用者，他們的業務場景，工作內容必然會有區別，我們不能把他們各自使用的功能權限放在一個模塊內，這會帶來很多問題：
1、A和B的模塊發展方向完全不同，導致模塊的發展南轅北轍；
2、A和B的模塊關聯度很低，產品功能上兩者聚合在一起顯得毫無意義；
3、用戶不希望A的模塊可以被B看到和使用，兩者的權限不同，但是由於同屬一個模塊而導致權限非常難劃清邊界。
所以對於不同職能／角色的使用者，儘量將他們各自所要用到的產品模塊拆分開來，保持各自的獨立性，是模塊劃分的一個重要依據
3、關注數據流
業務流程可能會以一個人、或一個主體為中心進行流轉。
而數據流是隱藏在表象之下的另一個流程，他是以數據為中心進行流轉的。
一般來說，C端產品的數據流，基本只需要考慮前後臺的數據流轉情況即可。但是B端就會複雜一些，B端saas產品數據往往貫穿C端功能，還會出現跨平臺、跨模塊的數據流傳。
數據流的作用，能幫助你更清晰的劃分模塊。
四、如何設計產品結構？
1、產品結構設計的範圍
產品結構設計包含多層維度的設計。主要有如下5層維度
系統層面的結構——如何分平臺／系統
版本層面的結構——如何分版本／權限
模塊層面的結構——如何分模塊／二、三、四、五級模塊
頁面層面的結構——如何分頁面／頁面信息
產品內在邏輯結構——如何用邏輯串聯
產品結構的在用戶端的展現就是信息結構。這點相信大家都懂，無非是頁面層級、頁面內部信息層級的劃分、信息內容的分類和展示。
其次就是產品內在的邏輯結構：
比如某個配置項應該放在功能模塊內還是基礎模塊內？
比如在連鎖系統中，會員是放在連鎖維度還是單店維度？
比如直接在營銷活動中創建電子券，還是先在電子券模塊中創建，然後營銷活動進行引用？
這些其實都屬於產品功能層面的架構。
2、產品內在邏輯架構設計的7個核心原則及10個案例
1、易用性——從用戶使用體驗層面考慮
2、可擴展性——迭代、修改的成本最小化
3、技術實現性價比——技術實現成本是否過高不匹配功能價值，按性價比高的去設計
4、普適性——每個單元模塊是否可以被其他單元無限重用
5、熟悉業務——違反業務習慣的邏輯設計不能出現
6、掌握產品發展方向——預見產品在中短期內的發展方向，提前考慮進去
7、從簡單到複雜——任何一個產品都是從最小MVP開始的，千萬不要在開始就架構一套複雜的系統
關於一些結構設計上，我給大家列一些比較高頻出現，比較常見的B端產品（不同緯度的產品架構思路）小例子：
1、比如我們有一套面向商家的門店經營管理系統，這時需要一個有一個卡券平臺，跟門店管理系統中的業務有著密切的關係，這個時候你該定義這是一套系統還是兩套系統？他們的關係是什麼？邊界在哪裡？
2、比如我們做了一套診所管理系統，後續要垂直化專科式發展，那麼到底是通過拆分版本，完全一個科室一個獨立的版本？還是做在一套系統裡，然後通過權限劃分 更合理呢？這其實就是產品架構的一部分
3、比如對於電商類的saas，很多是非協作型的，也就是說模塊之間並沒有嚴格的強聯繫，相對比較獨立，獨立作為一個B端業務閉環，可單獨使用。但是像診所saas，則是協作型的，即業務流程涉及到多模塊多角色，每個角色都需要在流程中承擔一部分工作職能。非協作型和協作型的系統設計的思路也是不同的
4、比如我們在設計電子券的時候，我們是通過一個步驟完成創建+投放，還是通過創建一個步驟+投放一個步驟完成流程？背後的考慮因素是什麼？
5、對於一些業務流程的設置項，是放在後臺該業務模塊維度，還是基礎設置模塊的維度？
6、比如原先要設計商品管理模塊，考慮的主要是單店模式，跨店的商品管理是隔離的，但是當跨店客戶提出想要統一管理商品，並可以支持總分店和分店之間的商品調撥的時候，單店商品管理的設計方案就無法支撐這樣的業務模式，需要做大規模的底層改動
7、確定維度，比如哪些指標是單店維度，哪些是機構維度，比如預約是放在後臺“診所管理”裡面，還是單獨放在後臺“預約管理”中？放在哪個維度又是基於哪些原因考慮的？
8、業務的不滿足性，比如我們在做一款電子券的時候，考慮了線上場景，但是還要考慮線下場景，這就需要電子券模塊下需要投放到線上（多個渠道）、線下（二維碼、短信等），那麼渠道後續可能會進行變更，那麼假如我們把創建+投放一步完成，那麼未來我們要改動渠道，就會影響整個卡券流程，如果我們能分2步，那麼只需要對第二步投放進行修改就行，這樣系統的可擴展性就會強很多
9、比如對於訂單模塊的架構設計，是否能夠支持各種營銷活動：滿減、卡券、積分抵扣等，具備足夠強的業務包容性
10、重複被使用的模塊，如何避免重複造輪子！比如電子券模塊，在很多營銷活動中都會用到，比如短信消息模塊，在很多業務中都會用到，那麼這些被高頻用到模塊就應該抽離出來，而不是每個業務環節中都去做一遍。
3、產品架構必備能力
當然作為一個產品架構師，要完成這些事情，對於能力的要求也是非常高的，最主要的4點。
1、懂業務
2、預見能力，預見未來業務流程、業務模式的變化趨勢
3、成熟的B端產品結構化思維
4、懂技術原理，懂技術原理最大的好處就是能大概評估這個設計方案的技術成本，並推動自己選擇更合適，投入產出比更低的設計方案
總結
產品架構其實是一個非常複雜而宏大的話題，這篇將近5000字的文章也只是起了個頭。
我想說的是，產品架構不只是給產品搭個框架，他出現在產品設計的方方面面中。
通過這樣的架構思維幫助產品最均衡的匹配用戶的多樣性需求，匹配公司的大研發資源，匹配合適的時機把產品做到合適的程度等等。
這是一個系統性的工程，好的架構能夠支撐業務發展多年而不重構，更能讓用戶嘖嘖稱讚。
我想這就是產品架構的魅力吧！
閱讀更多 運營增長 的文章
