編輯導語：一個好的產品架構，需要能夠助力商業模式、體現公司目標、具備落地性，同時具備抽象能力和擴充套件能力。本文作者從這幾點出發，分析如何設計出一份好的產品架構，一起來學習一下吧。

在上篇文章中我們重點講述了業務調研，業務調研是我們架構設計的基礎，只有瞭解清晰業務形態，整體流程及相互關係之後，才能設計出符合業務形態的產品架構。

產品架構是將具體的業務功能按照一定規則組裝成業務模組，將不同業務模組按照一定規則進行劃分和歸攏，並用圖形或者文字把各模組之間的關係表達出來的邏輯模型。

接下來這篇文章跟大家分享和交流我們如何設計出一份好的產品架構。

01 什麼是好的產品架構

一個好的產品架構需要

能夠助力商業模式、體現公司目標、具備落地性，同時具備抽象能力和擴充套件能力

。抽象能力的適應性體現在其匹配的行業，抽象能力較好的產品架構可以適用於多個行業，支援其橫向的覆蓋範圍。

而擴充套件能力適應性體現在其可以包容接納的領域，擴充套件性好的產品架構，各模組之間邊界清晰、職能明確、相容性強，可以在演進的過程中，將更多的領域納入到自己的架構中，成為整個產品的一部分，並且可以實現接入過程，成本低、時間短、少出錯。

總的來說產品架構的抽象能力能幫助產品適配多個行業，支援橫向覆蓋

；能幫助產品適配更多的領域，支援縱向演進。抽象能力和擴充套件能力代表了一個產品在不同維度的適應性。

02 產品架構的核心要素

在進行架構設計之前我們需要了解產品架構所包含的要素，透過我們對上文產品架構是什麼的理解，我們可以將

產品架構拆分成功能、模組、域、層、邏輯關係幾個維度

。

在架構設計過程中將不同的功能匯聚成模組，而模組的劃分需要遵循一定的規則，根據角色、場景、互動操作等去進行功能塊的聚合。不同模組可以進一步聚合形成域，域是模組根據某個場景聚攏而形成的，域可以支撐某一個場景下的一系列操作，輸出一個閉環的能力。

而層則是某幾個域和模組的組合，層實現了向下整合或向上支撐的統一化的能力。邏輯關係指層、域、模組之間需要有清晰地邏輯關係，包括輸入輸出、職能邊界等等。

產品架構是一個沒有標準化量化好壞的東西，在做產品架構設計時不可避免的需要考慮多角色訴求，

產品經理在設計產品架構時一定要多角度，多維度去綜合考慮，達到一個相對平衡的結果，這一點尤為重要；

其次產品架構設計時也需要充分考慮商業模式，這一點也至關重要。

同時我們在日常工作中也常聽到技術人員說架構，技術架構與產品架構兩者是兩個層級的東西，產品架構是技術架構更上一層的邏輯，是進行技術架構的設計時所必須的業務依據，而技術架構是對產品架構的實現邏輯的反饋，是產品是否可以按照這樣進行設計的技術依據，兩者之間相輔相成，有依託也有支撐。

03 如何保證產品架構的抽象能力

對於SaaS產品來說其面對的客戶是相對廣泛的，不同的客戶所處的發展階段也不盡相同，甚至我們能夠看到同一型別的客戶，他們的訴求也會存在一定差別，正因為如此我們需要對服務客戶的業務進行抽象，找到自己所面臨的的客戶群體，找到這些群裡存在的共性、差異性。

那我們在產品架構設計中如何去解決個性化與標準化共存的問題，而解決這個問題我們需要去做三件事：

1. 拆分產品戰略

我們之所以要拆分產品戰略，因為產品架構需要體現客戶的意志，明確客戶想做什麼？先做什麼？後做什麼？那些部分要做到什麼程度？戰略的拆分是想透過產品架構的設計來表達客戶最終想要的樣子，以及產品是按照什麼路徑演進到最終客戶想要的樣子。

整個路徑中有那些關鍵節點，而這些關鍵節點就是我們的里程碑，所以我們才需要去拆分產品戰略。

1. 拆分產品戰略

業務戰略是以實現營收，節約成本作為目標的，業務戰略相對清晰可衡量。而管理戰略目標則相對模糊不易衡量，往往涉及企業內部管理。針對業務戰略我們透過三表法的方式去分析和拆解，針對管理戰略我們以場景代入的方法進行拆解，下面跟大家一起看看具體的執行方法。

拆分產品戰略主要是指拆分企業的業務戰略和企業的管理戰略。

第一步：拆分內容，進行匯聚。

目標表：要達成什麼結果，這些結果由哪些小目標組成的，小目標對整體結果貢獻度是什麼

策略表：策略表是針對需要實現的目標給出一對一或一對多的落地方案的解答，怎麼達到我們預定的結果，分幾步進行，每一步的玩法是什麼，每一步階段性成果如何衡量

資源表：需要什麼支援，需要多少，需要多久

第二步：分類彙總，合併歸納。

針對目標表：那些目標是相似的，那些目標是有因果關係的，那些目標是相互依賴或衝突的

針對策略表：那些策略是相同或者相似的，那些策略是有先後順序的，那些策略之間是衝突的

針對資源表：那些資源是共享的，那些資源是獨享的，那些資源是相互依賴的

根據相似相同的內容合併總結共性；無法合併的部分，分析其差異性，根據共性與差異性規劃產品的大模組。

第三步：建模。

組合產品大模組建立初步模型

組合職能相近模組，逐步拆分層、域、模組，在架構圖中分層著色

串聯模組關係，明確模組內部資源，依賴外部能力輸出

標識整體及小目標，制定roadmap，定各階段的落地策略

透過上面三步我們就能獲得初步的產品架構圖，以及這個架構圖也能初步體現出產品在不同階段是什麼樣子，在之後我們不斷反推，不斷修正。

1）透過三表法拆分業務戰略

管理戰略很多都是重視流程的，因為流程代表了標準化的流程和透明化的進展，以及明確的執行節點和確定的執行結果。所以我們場景代入法來思考。

在場景代入法中代入一般會根據特定約束進行假設，比如假如我是管理者/操作人，在XX情況下我會需要關注那些事情。在之前的文章中我們也提到過流程的五要素：

場景代入法則關注流程五要素中的三個要素：典型場景（正向場景、逆向場景）、典型角色（管理者的關注點、操作人的關注點）、典型行為（正常的行為、非正常的行為）。

在做場景代入法時很多時候我們只考慮了正向場景，而對逆向場景會有忽視，同時也會出現遺落不同的關鍵角色而進行架構設計和規劃的情況，所以

2）場景代入法拆分管理戰略

在做場景代入

。

時我們要充分考慮正向與逆向的場景和與之對應的不同角色，儘可能考慮周全

在此之前我們分享過如何去做市場分析、產業鏈分析、商業模式分析，其本質還是回到我們如何去理解客戶業務的本質，

2. 抽象客戶業務本質

。

2. 抽象客戶業務本質

在上一步中我們透過拆分產品戰略，將規劃的產品模組進行組合，依據客戶的商業模式建立符合客戶戰略的初步產品模型，其中客戶的商業模式就是客戶業務本質的體現，客戶組織架構是管理本質的體現。

需要明白客戶是什麼，他們透過什麼去賺錢的，他們的玩法是什麼，是需要什麼樣的產品來支撐他們日常運營管理的

而從模型回到業務本身，這個過程是一個推演的過程，畢竟產品是要落地到最終的場景和具體的業務當中去，所以產品的架構要在模型的基礎上考慮業務的實際場景，與此同時在產品功能模組設計上要針對客戶的痛點。

所以抽象客戶業務本質我們需要站在一定的高度，同時也要接地氣，要掌握好兩者之間的平衡，這也是衡量一個產品經理產品設計能力好壞的一個標準。

抽象客戶本質是一個從現象到建模，再從模型回到業務本身的一個過程。

高內聚低耦合在產品架構設計中，是用來描述產品內部各模組之間的關聯關係以及產品模組本身的能力的。

具備高內聚低耦合的產品架構能夠清晰地向客戶描述產品是什麼樣的，也可以告訴技術人員怎麼設計技術架構，所以他是要銜接技術語言與業務語言圖形化的方式。實現高內聚低耦合我們需要在產品架構上做到

從業務角度來說產品的架構模型需要滿足客戶的商業模式，從管理角度來說產品的流程設計要符合行業通用的玩法。

3. 高內聚低耦合

分層是一個功能維度上的概念，可以按照服務的物件不同，分為使用者層、業務層、資料層。

使用者層：將所有面向用戶的功能集合在一個層級，使用者層需要考慮不同的使用者群體所享受的服務存在差異。

業務層：將所有的業務處理規則和邏輯，整合在業務層，業務層對使用者層有邏輯支撐，業務層在不同的場景下整合的規則和能力都是不同的，向上輸出也不盡相同。

資料層：將所有的資料沉澱，資料處理整合在了資料層，資料層提供基礎的跟資料相關的增刪改查服務，這些服務供業務層呼叫，在不同的場景下沉澱不同格式的資料。

分層同時有上下游概念的，比如供應鏈電商他的產品架構是可以分為交易平臺層、供應鏈層的，交易平臺核心在於撮合交易由商品、會員、訂單等組成，供應鏈層則主要負責售前的採購以及售後的履約行為等。

產品架構是對業務分層設計的過程，不同的分層資訊展示的側重點也就不同，比如按照功能維度進行了分層，分成了使用者層、業務層、資料層。

使用者層：考慮如何更好的表達業務元素，如何能夠更吸引使用者的注意力和停留決策，千人千面或千客戶千面是這一層想要達到的效果。

業務層：核心是解決產品核心功能設計問題的，如何高效地完成場景下的業務需求，是這一層關注的重點。

資料層：與使用者隔離的黑箱，決定了所有業務問題的集合。

3. 高內聚低耦合

分層之後我們進行分域，分域進一步降低耦合，再提升一部分的內聚。

分層、分域、職能邊界明確、輸入輸出清晰。

，常規所見的比如ERP域、交易域、流量域等等，與此同時

1）分層

，最常見的比如滴滴租車域、專車域、順風車域等，這種劃分的本質也是逐步在擴充我們業務邊界，也是產品生態的不斷擴容。

這種劃分主要是有利於企業內部跨主體，跨業務線之間的配合，

2）分域

，支撐域、整合域、消費域這類劃分方式，這種方式劃分域能夠把能力聚合在一起向外提供統一服務。而整合域更像是一種解決方案的聚合。

域一般情況下可以考慮按照業務職能進行劃分

。

完成分層分域之後我們整體的架構相當於已經完成了一大半了，整體長什麼樣子基本清晰了，那麼下一步就是我們對這個圖進一步進行調整和優化了，確定清晰各職能邊界和輸入輸出。

產品架構設計的粒度，從大到小應該是

域也可以根據業務線或業務主體進行劃分

這個順序，其中分層分域主要解決降低耦合的問題也兼具解決了一部分內聚的問題；而職能邊界與輸入輸出解決高度內聚的問題，同時兼具降低耦合。

這兩者側重點是不同的，這也是我們產品設計時需要圍繞的設計理念。接下來我們看看如何確認各模組之間的職能邊界與輸入輸出：

保持適當的抽象，滿足客戶的本質訴求，切莫流於表面，抽象和演繹是一個不斷迴圈的過程，內聚與耦合是一個相互平衡的結果。

04 如何保障產品架構的擴充套件能力

域也可以按照系統的關係來進行劃分的

不斷迭代驗證，最佳化更新，所以產品架構需要具備一定的擴充套件性。

其次設計一個產品並不是一開始就將所有的功能模組全部落地，而是有先有後，有主有次的過程。所以產品架構需要考慮演進的路線和實際，也是需要擴充套件性的。

B端產品並非都是從0到1的，而是有可能出現從0。X到1或者是從1到X的情況，需要產品的設計者依託於現在的產品架構，思考如何演進到未來理想中的產品架構，所以才需要我們的產品具備可擴充套件的能力，不具備擴充套件能力的產品容易在產品演進的過程中推倒重來，這對企業來說是災難性的，時間的成本遠遠大於金錢損失的成本。

當然我們也能夠按照技術職能進行劃分的

其中確認產品架構的演進藍圖，是明確產品演進需要走得路，明確路上所需要經歷的里程碑；明確產品架構的三個部分是將產品元件化、產品標準化，然後讓產品像搭積木一樣，有利於在產品演進過程中的拆分和新增重構。

取捨架構的模組是確定產品做什麼，不做什麼，先做什麼後做什麼。需要做的部分我們要做到什麼程度，是做到極致還是取捨平衡。這是考量產品經理格局的非常重要的一個點。

層、域、模組、功能

產品架構的演進需要考慮清晰我們產品現在的樣子，產品未來的樣子，產品每一步的樣子。

產品架構並非是一成不變的，需要隨著業務的發展，商業模式的變化與時俱進。

產品架構想要具備擴充套件性，就需要考慮將產品的模組按照其在架構中可能涉及到的變化頻率分為三個類別：

確保產品架構的擴充套件能力我們需要做三件事：

作為不可變或低頻可變的內容，用於設計產品最核心，最具競爭力的部分；大部分產品架構中資料層都是核心層，核心層提供的能力是最內聚的，是產品的底座。

1）確認產品架構演進藍圖

是指將一些垂直的場景內聚到域當中，域內的能力是相對集中的，透過跨域的組合搭建不同的商業場景，組合層的能力決定了產品的靈活性。

2）明確產品架構的三個部分

定製層主要指差異化的部分，差異化的部分是可以進行定製的，定製出來的功能模組需要組合層的支撐，組合層提供的能力越多，那麼定製層的定製能力則越強，擴充套件性就越好。

還有一般邊界相對模糊，大多用於模組之間的互動的部分歸納成其他部分，我們常見的比如API層面。

這幾層之間是會隨著業務的發展逐步轉化的，比如定製層的業務在某一個方向上他的體量有顯著的增長，這時候產品的邏輯會固化起來，那麼這些固化的內容就會逐步演變成支撐某些特定的商業場景的組合層，甚至某些組合層的能力進一步抽象，抽象出來的部分我們發現變成了低頻可變的部分，這個部分就可以下沉到核心層。

具備了這三個部分的能力的產品架構，已經具備相當不錯的可擴充套件的能力了，主要體現在大部分業務的特性化訴求，都是可以透過定製層來滿足的，少部分具備一定抽象能力的訴求，可以在組合層中來支援。

這樣我們核心層基本不動，產品改造、新模組進入都是相對比較快的，只有當出現大的技術變革或業務方向發生調整之後，核心層才會發生改變。

核心層：

產品架構是用來落地的，所以落地的過程就是要有先有後，不是同時開始的，B端產品的設計需要考慮每一步的樣子，所以在明確整體的產品架構以後，就要去想下一步要做什麼，

組合層：

定製層：

。

但是產品設計在最初階段遇到無法取捨，不好取捨，因為看上去每一個模組都是必須要，我不做什麼都會產生影響，每一個模組之間都有關聯關係，先做誰都不好，基於這種情況給出四個取捨維度：

取捨的原則看上去確實很簡單，或者別人告訴你這個需求緊、價值高、關聯性強、落地性也好，也都可以去做取捨，

3）取捨架構模組

我們產品要做的東西那麼多，那麼在設計時我們一定要做一定的取捨，什麼都

想做是產品設計的大忌

有時候產品經理獲取到的資訊可能是所有人都說這個需求緊急，價值高需要優先去做，這兩個模組之間關聯性強應該要兩個都做等等，這時候產品經理又該如何去做判斷？

遇到這種情況也給大家推薦兩種取捨方式，正向：這個模組我取，有什麼好處，落地難度如何？逆向：這個模組我不取，有什麼壞處？在這裡面逆向的推演需要考慮的東西更多比如這個模組捨棄對整個產品會造成什麼影響，不上這個功能之前的解決方案是什麼樣的，產品不做這個，原有解決方案是不是還能用等等。

在很多時候我們可能會有臨時替代方案去做產品，但是在做臨時方案設想時需要考慮清楚，解決方案的代價如何，是否能夠滿足一個階段的執行，另外我們在何時進行臨時方案的替代。

但是本質

05 結尾

最後我們再一起回顧下透過文章可以瞭解到，我們如何去做一個好的產品架構，以及我們可以透過助力商業模式、體現公司目標、落地性，抽象能力和擴充套件能力這五個維度去衡量一個架構的好壞。

那麼我們再串聯一下之前的幾篇文章，整個產品的架構設計流程我們從最初的市場及產業鏈分析再到現狀與目標客戶分析，再到確定模組與場景域，最後進行架構圖設計，而產品架構設計的粒度，從大到小應從層、域、模組、功能。到這裡B端產品規劃設計階段就結束了。

作者：張二十三

本文由 @張二十三 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議