如何寫好B端產品的技術方案？

B端產品為企業提供協同辦公的工具，幫助企業解決某類經營管理問題，核心價值在于為企業增加收入、降本提效、管控風險，企業級SaaS產品也是B端產品中的一類，

B端產品有以下特點：

?客戶是一個群體：B端產品為某個企業組織服務，一項作業通常需要由多名角色完成，例如，門店要貨流程，需要門店店員、總部運營、倉儲人員、配送人員共同完成，B端產品幫助他們完成分工協作，

功能繁雜：由于B端產品涉及企業經營的方方面面，關聯的用戶角色、業務流程非常繁多，反應到產品上，選單、界面、配置項特別多，復雜度遠高于C端產品，為了實作一項功能需求，往往會影響其他許多功能，需要進行全面的梳理，考慮各種極端情況，才能保證整體功能正常，

定制化功能：B端產品必然會有很多定制化需求，如果一味抗拒，很容易丟掉一些優質客戶，但如果大包大攬地接受，系統復雜度會指數級上升，高昂的研發維護成本將很難承受，所以如何處理好定制化需求，是一項非常艱巨的任務，

見效慢、難量化：由于B端產品的客戶是一個群體，產品上線新功能，通常是管理層先評估，能否在企業中適用，如果合適，才會組織一線人員，進行操作培訓，這樣一來一回，可能要2個月后才有客戶正式使用新功能，

其次，業務見效的影響因素非常多，很多時候并非因為B端產品設計問題，例如，采購部門核心目標是找到更多優質、低價供應商，而這主要依賴采購員的專業能力，以及商家的管理能力，很難衡量產品功能對商家業務的實際貢獻，

正是由于B端產品這些復雜性，要寫好一份B端產品的技術方案，是非常有挑戰的事情，對最終專案價值達成起到決定性的作用，技術方案質量差可能直接毀滅一塊業務，下面推薦一份B端產品的技術方案模板，供讀者參考，

一、概述【強制】

1.1 術語解釋

為什么要這塊內容？

B端產品中的專業名稱非常多，對專業名詞進行匯總解釋，方便專案組理解背景關系，統一認知，

1.2 專案背景與價值

為什么要這塊內容？

介紹專案的背景，為什么需要做這個專案，解決了用戶哪些痛點，為用戶創造什么價值，或者是技術價值，例如，帶來多少活躍商家數？提升多少NPS？性能有多少提升？開發效率上有多少提升？

這部分內容極其重要，前文提到B端產品見效慢、難量化，但這并不代表只能自暴自棄，不去進行收益分析，相反，我們需要更加努力地對B端專案進行收益分析，即使最終也很難找到合適的度量方法，思考如何度量收益，這個程序本身就能幫助決策該不該做，如果一件事很難度量，同時放飛自我，不去謹慎思考，最終專案大概率失敗，

站在技術視角，系統復雜度無節制地增加，很重要的一個原因是由大量無價值的專案累積起來的，最終演變成一座“代碼屎山”，在專案初期，多追問專案的價值，專案上線后，也追著產品設計者回顧專案價值，能有效避免這種情況，讓技術人員的付出更容易獲得結果，

1.3 本期專案目標

介紹本期專案需要達成的目標

1.4 方案評審紀要

為什么要這塊內容？

一個復雜專案，通常需要好幾次評審才能通過，記錄每次評審紀要，根據評審建議改進，是非常重要的，

二、業務分析【強制】

2.1 業務用例分析

為什么要這塊內容？

業務用例，是指參與者為完成某個特定業務目標的一系列活動的集合，用例圖用于描述系統與用戶之間互動關系，用例圖關心的是系統為用戶提供什么價值，而不是如何實作系統功能，它驅動了后續各階段的研發作業，如果用例分析出錯，很可能導致專案目標失敗，

業務用例希望我們跳出系統功能，以用戶視角來看待系統，思考什么場景下為誰提供什么服務？這樣才能以用戶為中心獲取需求，設計產品功能，同時這種視角也是用戶最容易理解的邏輯，

舉例說明

小專案如何設計？

在原有業務用例圖的基礎上，需要補充新用例或標識出待修改的用例，并在圖中用不同顏色標記出來，如上圖所示，紅色表示新增用例，黃色表示變更用例，

2.2業務流程分析

為什么要這塊內容？

業務流程，是指為達成特定業務目標，由不同的角色分工完成的一系列活動，活動之間不僅有嚴格的先后順序限定，并且活動的內容、方式、責任等也都必須有明確的安排和界定，讓不同活動在不同崗位角色之間進行流轉與交接，

業務流程對于B端產品的意義不僅在于對B端客戶業務的一種描述，更在于產研團隊對B端業務運營的理解和剖析，這種理解是對企頁澩的優化、對企業組織機構的優化以及對管理制度的一系列深入探究，只有真正理解業務流程，才能幫助B端客戶達成期望的目標：降低企業的運營成本，提高對市場需求的回應速度，爭取企業利潤的最大化，

對于研發人員，業務流程模型可以幫助研發人員更好地了解企業真實的運營場景，進而更好地實作客戶的需求，

舉例說明

小專案如何設計？

在原有業務流程圖的基礎上，需要用不同顏色標識出需要修改的部分，

2.3概念模型分析

為什么要這塊內容？

概念模型，是指從業務視角出發，聚焦業務流程、業務活動中涉及的資訊資料，抽象出關鍵業務物件，并描述這些物件間的關系，

概念模型實際上是現實世界到數字世界的第一層抽象，通過觀察業務中關于資料的采集、傳輸、處理、存盤、輸出等需求，經過分析、總結之后建立起來的一個邏輯模型，它主要是用于描述業務系統中資料的各種狀態，

概念模型不關心具體的實作方式（例如如何存盤）等技術細節，而是主要關心資料在業務流中各個處理階段的狀態， 

想要全面地了解某個業務領域，首先要了解該業務是什么，其次就要了解業務內部的核心運作原理，即從靜態到動態，從目標到程序，系統地理清業務的框架和脈絡，

業務的動態描述可以通過活動圖，流程圖，時序圖，泳道圖等模式描述，而業務的靜態描述首先要分析出概念模型，

舉例說明

三、方案選型分析【可選】

為什么要這塊內容？

有些專案比較簡單，簡單到不需要花太多時間做方案決策，

但一些成本大、風險高的大型復雜專案，會讓人感覺到頭疼、焦慮，這些專案的技術方案的決策結果，很可能摧毀一個專案，甚至一塊業務，

為了避免做出錯誤決策，需要一系列的分析步驟，幫助我們做出正確的決定，保障專案目標順利達成：

1.詳細的現狀分析：很多專案失敗，原因是一開始就沒分析清楚問題，在這個環節，需要明確真正的問題是什么，它與各個問題癥狀的因果關系是什么，常用的分析工具有五個為什么、根因分析法等，

2.核心成員同頻：一個復雜專案，通常需要很多人參與，有人是受益方，有人是受影響方，有人是決策者，需要讓核心成員盡早參與進來，并營造一個積極的討論氛圍，讓每個人充分貢獻自己的想法，這對做出正確的決定至關重要，

3.充分挖掘可行方案：挖掘出的可行方案越多，最終得出最優方案的概率就越大，

4.方案對比分析，選擇最優方案：通過一些分析維度，對比方案的優劣，最終選擇最優方案，分析維度可以通過團隊頭腦風暴篩選得出，或其他方法得出，這里推薦幾種常用的分析維度：

• 交付效果：該方案是否對最終交付給存量或新客戶的價值有影響，例如，對存量客戶的操作體驗、效率有損，部分新功能無法實作等，

• 作業量：該方案需要多大的作業量？這是非常重要的一個決策因素，方案再好，無法真正落地也只能是空想，

• 影響面：該方案涉及多少關聯方改動？如果影響全公司所有部門，即使每個部門改動量不大，但要協調這么多人，也是一項非常艱巨的任務，

• 穩定性：專案上線后是否有資料庫性能問題？服務器資源不足？并發流量問題？能否平滑發布？歷史介面或資料能否兼容？

• 長期價值：該方案是不是長期方案？有時候對方案做長期投資也是很重要的一件事，短視的方案雖然作業量會減少一些，但會阻礙未來新專案迭代，欠的技術債可能要加倍還上，

5.向更多專案成員傳達方案，進一步優化：通過上述步驟，可為最終方案提供大量的資訊，例如，根本問題、風險、收益、替代方案、決策方式和決策的原因等，這會讓更多人有理由支持該方案，在傳達的程序中，也可能有人指出方案的缺陷，這時可以進一步完善方案，這時對方案的改動，成本非常低，如果等到進入研發階段，昂貴的代價可能無法接受，

舉例說明

方案1：，，，（描述）

方案2：，，，（描述）

方案3：，，，（描述）

四、業務平臺化設計【可選】

為什么要這塊內容？

業務平臺化是將多業務線可復用的能力抽取出來，并集中管理和演進的架構方案，

一方面，可讓企業避免重復建設，浪費技術資源，另一方面基于平臺化的能力，讓新業務快速組裝上線，支撐業務創新，

4.1 業務能力建模

為什么要這塊內容？

業務能力描述了應對當前和未來的挑戰，企業目前能做什么或需要做什么，業務能力建模的關鍵點在于它定義了企業做什么，而不是如何做（由業務流程描述），

以招聘業務為例，大部分公司都需要“招聘人才”這項業務能力，“招聘人才”告訴我們要做什么，但并沒有展開說如何去做，可能是通過人力資源的招聘流程實作，例如，從招聘網站吸引候選人，再到招聘資訊的管理，也可能外包給獵頭公司，

業務能力獨立于組織的結構、流程、人員、資產，準確地說，這些業務要素是支撐企業的業務能力而存在的，還是以“招聘人才”為例，“招聘人才”包括人力部門（人力資源團隊）、業務流程（例如吸引、篩選、面試、雇用）和IT系統（例如招聘系統、人事系統），準確的業務能力是非常穩定的，在過去的幾十年中，招聘的流程、技術、模式發生了翻天覆地的變化，但“招聘人才”這項業務能力始終恒定存在，

正是因為業務能力的這些特征，業務能力視圖對構建IT架構提供了至關重要的幫助，圍繞業務能力構建的IT系統會具備更加穩定的結構，并易于擴展，

具體來說，業務能力視圖有以下2大應用場景：

1.產品定義與演進路線圖，如果需要推出的新產品或服務，可以使用業務能力地圖來描述產品規劃，尤其在基于敏捷、最小可行產品 (MVP)的文化中，業務能力地圖可以在定義產品的同時，保持最終產品方案的正確性，不至于在偽敏捷文化中迷失自我，

2.基于現有能力快速搭建新應用系統，通用能力很可能被多條業務線復用，當新業務需要搭建新應用系統時，合理地對現有能力進行組合是最高效的方案，此時業務能力圖可能是最重要的輸入，

舉例說明

4.2 系統作業流與擴展點設計

為什么要這塊內容？

基礎能力是對領域物件的原子操作，是可復用的最小能力單元，擴展點是對基礎能力的可變性設計，而業務身份是業務能力在業務平臺上的唯一標識，

在技術視角下，基礎能力可對應于服務介面，將基礎能力的內部實作展開，即為一個系統作業流，而擴展點是指系統作業流的某一步驟級介面，這個步驟級介面的實作即為一個擴展點實作，基于業務身份，可實作作業流內部組件的路由、鏈路溯源、鏈路監控、業務隔離等，

有了擴展點機制，我們就可以基于現有基礎能力，快速實作定制需求，

舉例說明

五、概要設計【強制】

5.1 限界背景關系劃分

為什么要這塊內容？

在業務分析環節，我們需要分析業務流程、業務活動，根據業務目標的相關性、耦合關系，對業務活動進行歸類分組，劃分出一個個的邊界，這個邊界就是限界背景關系，

限界背景關系內包含一組能夠獨立提供服務的模塊或組件，這些模塊或組件服務共同的業務目標，

限界背景關系的價值主要有：

1.基于業務目標的相關性，維護了一個分解后的邏輯邊界，將相關的模型封裝在內，對外提供抽象簡化后的服務介面，降低了系統整體復雜度，

2.以限界背景關系定義的邏輯邊界為基礎，建立團隊間的協作邊界，團隊間同樣以服務介面進行互動，屏蔽內部的業務復雜度與技術復雜度，

舉例說明

5.2應用架構設計

為什么要這塊內容？

應用架構描述出應用系統的層次結構，包括系統、應用、模塊、組件等構件的劃分規范，以及它們的定義、邊界、相互間的互動協議，

畫應用架構圖，推薦西蒙布朗提出的C4模型，它將應用架構分為4個抽象層次，分別為系統級、容器級、組件級、代碼級，

舉例說明

容器級應用架構：

組件級應用架構：

5.3 領域模型設計

為什么要這塊內容？

領域模型是對業務知識的抽象與濃縮，它能夠有效幫助業務人員、技術人員快速理解現實業務，同時也是團隊統一語言的關鍵，

在DDD理論中，領域模型包含限界背景關系、領域物體、聚合、值物件、領域事件、倉儲、應用服務、領域服務等，以及它們間的關系，

舉例說明

小專案如何設計？

在原有領域模型的基礎上，需要補充新的模型或新屬性，并在圖中用不同顏色標記出來，如果沒有模型變更，可以不需要這塊內容

5.4 容器級互動時序

為什么要這塊內容？

容器級互動時序圖是一種流程建模，描述了應用容器之間的互動順序，將互動行為建模為訊息傳遞，通過描述訊息是如何在應用容器間發送和接收，來動態展示它們之間的互動，相對于其他UML圖，時序圖更強調互動的時間順序，可以直觀的描述互動的程序，

舉例說明

小專案如何設計？

在原有互動圖的基礎上，需要補充新的呼叫關系，并在圖中用不同顏色標記出來，例如，用紅色線條標識為本期專案新增，

六、詳細設計【強制】

6.1 組件/代碼級互動時序

為什么要這塊內容？

相比于容器級互動圖，組件或代碼級的互動圖是更細粒度的互動流程，描述了應用容器內各個組件或代碼的互動順序，

舉例說明

小專案如何設計？

在原有組件間互動圖的基礎上，需要補充新的呼叫關系，并在圖中用不同顏色標記出來，例如，用紅色線條標識為本期專案新增，

6.2 領域模型詳細設計

6.2.1 領域物體&值物件定義

XX領域物體

XX值物件

6.2.2 領域服務定義

XXDomainService

6.2.3 應用服務定義

XXAppService

6.2.4 領域事件定義

XX領域事件

6.2.5 領域物體狀態機定義

舉例說明

要貨申請單的狀態機：

6.3 物理模型詳細設計

為什么要這塊內容？

物理模型是指按照一定規則和方法，將領域模型中定義的物體、屬性、屬性型別、關系等要素轉換為資料庫設計所能夠識別的表關系圖，即我們常說的資料庫表結構設計，

舉例說明

XX表結構

6.4前端介面詳細設計

介面名稱：XX

入參設計：

回傳值設計：

錯誤碼解釋：

七、非功能性需求設計【強制】

為什么需要這塊內容？

非功能性需求是指軟體產品為滿足用戶業務需求，除功能需求以外必須具有的特性，包括系統的性能、可靠性、可維護性、擴展性、安全性等，

大多時候我們更關注功能需求，而容易忽視非功能性需求，但這些需求沒有做到位，也很容易讓用戶體驗受損，產品飽受詬病，我們在做技術方案時，需要有非功能性需求的checklist，避免遺漏關鍵的需求點，

7.1 性能分析

1.資料庫性能

評估新增的資料庫表的IO、事務數，是否有并發場景，是否有性能瓶頸，是否對現有業務或實時/離線數倉有影響，

若有高并發、熱點資料集中訪問等場景，需要有詳細的快取設計方案，

2.JVM調優

JVM引數是否配置合理，是否有參考線上標準配置，

3.外部系統性能

當前業務流量，下游系統能否支撐，是否需要做限流處理，

4.服務器性能

當前業務流量，對服務器性能是否有挑戰，建議通過壓力測驗，驗證服務器性能狀況，

7.2 穩定性分析

1.降級、熔斷、限流

在大流量、高并發場景下，熔斷、降級、限流是保護系統的利器，評估該專案是否需要使用這些機制，

2.灰度發布

評估該專案是否需要灰度發布，雖然功能在測驗環境測驗過，但生產環境的場景例外復雜，對于復雜專案很難全面評估，通過灰度發布，讓少部分用戶先使用新版本，提前發現bug，或者穩定性問題，提前做好修復，可以有效降低新版本帶來的影響，

3.監控報警

評估該專案是否需要新增或變更監控報警，監控報警能夠保障出現故障之后，第一時間知道，防止影響面擴大，

4.資料一致性對賬設計

分布式架構極容易出現資料不一致的問題，該專案是否需要設計資料對賬腳本，幫助及時發現不一致問題，

7.3 資損分析

1.評估資損點，例如服務介面中包含資損相關欄位（資金、積分、虛擬幣等），

2.評估為了防止資損，是否需要進行冪等控制、并發控制、越權校驗、風控機制設計、止損機制設計、監控報警設計等，

7.4 兼容性分析

1.歷史資料遷移

該專案對歷史資料是否有影響，若有，需要制定詳細的資料遷移計劃，

2.歷史版本兼容

該專案對老系統、APP歷史版本、開放平臺介面是否有影響，是否需要開發兼容邏輯，

7.5 安全分析

1.評估常用技術攻擊手段的防控，比如腳本（JS）注入、SQL注入、CSRF攻擊、越權問題、id遍歷、防重放攻擊，

2.資料是否需要脫敏，比如手機號等隱私、敏感資料，

八、附錄【強制】

8.1參考檔案

附上需求檔案、過往技術方案設計檔案、依賴的技術組件、技術服務的說明檔案等，給出檔案鏈接或附件，

參考資料

1.《ThoughtWorks現代企業架構框架白皮書》

2. https://c4model.com/

3.《實作領域驅動設計》作者：Vaughn Vernon

4.《領域驅動設計》作者：Eric Evans

5.《決勝B端：產品經理升級之路》作者：楊堃

本文來自博客園，作者：湯師爺說，轉載請注明原文鏈接：https://www.cnblogs.com/tangshiye/p/16197792.html

標籤：架構設計

上一篇：如何在docker中使用nginx將phpMyAdmin服務到localhost/phpMyAdmin而不是localhost:8080

下一篇：我的微服務總結