本文介紹了從技術架構視角來審視軟件體系是如何一步步發展演變，以及為什么說軟件工程就像是搭積木。

軟件工程是一項既復雜又簡單的系統性工程。說它復雜，是因為一整套良好運轉的體系是由數百萬行代碼構建而成的；說它簡單，是因為本質上軟件體系是無數組件化的小模塊拼裝而成的，每個研發人員或研發團隊只需要維護自己負責的組件與代碼模塊，復雜度會降低很多。

軟件的設計應該像搭積木那樣，通過自由拼接組裝來實現復雜的功能模塊，這樣既能保證系統的靈活性，又能避免重復開發，降低成本。如果不能將軟件分解成像積木那樣的小模塊，而是焊死的一塊鐵板，那么系統將徹底喪失靈活性。

軟件系統是如何像搭積木那樣拼接出復雜系統的呢？

我們以M公司的Passport系統的開發歷史為例，來看看“積木”是如何一塊塊被搭建起來的。

Passport系統是企業管理客戶賬號的平臺，存儲了客戶在企業中的注冊賬號等信息。用戶通過App或網站的“個人中心”對賬號進行密碼管理、郵箱管理等操作，“個人中心”可以理解成Passport系統的用戶前臺部分。

作為一套完整系統，M公司第一個版本的Passport系統在建設中遵循了經典的MVC范式，如下圖所示，數據層“Passport數據庫底層”存儲了客戶賬號、密碼等數據；業務邏輯層“Passport賬號管理服務”包含具體的業務邏輯代碼，例如綁定手機、解綁手機的處理邏輯；前端交互層“Passport用戶前臺”是C端的網站或App上的“個人中心”界面。

第一版Passport系統很好地支持了C端業務，但缺少一個很重要的功能，即供內部業務人員管理用戶賬號的功能。因此，公司決定開發一套“Passport管理前臺”，給業務人員使用。

現在問題來了：給業務人員用的Passport管理前臺需要單獨開發嗎？我們發現不論是給個人用戶使用的Passport用戶前臺，還是給業務人員使用的Passport管理前臺，絕大多數的功能都是類似的，例如重置密碼、修改關聯郵箱等，只是前端界面不同。針對這兩套高度類似的功能，如果重復開發一套業務邏輯代碼，就會浪費人力，也會造成架構的不合理。

合理的做法是對第一版系統業務邏輯層的核心功能進行服務化處理，即針對“注冊賬號”“禁用賬號”“重置密碼”“更新數據”等每一個目標很清晰的功能，將它們抽象成接口，以便于給任何系統提供支持。

因此，我們將后端系統進行服務化改造，并且開發Passport管理前臺，與Passport用戶前臺共用同一套服務接口。新版的技術架構如下圖所示，這依然是基于MVC模式的設計方案，只是對業務邏輯層（Passport賬號管理服務）進行了接口封裝。

接下來，業務發展對Passport系統提出了新的需求：

• 開展分銷業務后，也需要對分銷客戶開發前端界面。由于分銷業務和C端業務的差異比較大，因此分銷業務不打算使用“Passport用戶前臺”，而需要單獨開發“分銷業務前臺”，對賬號功能做一些處理。
• 公司的客服業務團隊希望根據客服人員業務操作的習慣和特點，把用戶管理功能做在客服業務系統中。

因為此時Passport系統已經高度抽象和服務化，具備強大的平臺能力，這些個性化訴求所需的后端功能接口都已成熟，所以業務系統只需要簡單地開發前端模塊并調用后端服務，就可以滿足各種個性化要求，系統的結構非常靈活，如下圖所示：

至此你應該感受到了軟件工程“搭積木”的設計特點，一個個服務接口就像積木塊，通過對這些積木塊的重復組合利用，可以搭建組裝出各種新的功能和服務。我們常說軟件工程就是在造輪子（服務接口和系統模塊），對于功能相同的輪子，大家共用一套就足夠了，沒有必要針對每個系統重復制造功能相同的輪子。

在第5章針對M公司分銷平臺的應用架構設計中，我們提到M公司各個系統已經實現了服務化，因此分銷平臺的很多功能模塊都可以復用現有系統，例如分銷平臺復用了客戶主數據系統、Passport系統、支付（Pay）系統、權限管理（Auth）系統、訂單中心、倉儲服務系統等。

這些被復用的系統（主要提供各種功能接口）就像一個個積木塊，重新搭配組合，支撐了分銷平臺的業務。上面的應用架構圖在一定程度上體現了這種復用關系，我們從技術視角繪制出技術架構圖，如下圖所示，讀者能夠從這幅圖中更清晰地感受“搭積木”的設計結構。

在技術體系中，有兩個非常重要的概念在支撐著接口化、服務化的設計理念的落地，即SOA（Service Oriented Architecture，面向服務的架構體系）和微服務。SOA和微服務從本質上講區別不大，只是微服務鼓勵去中心化，例如，上圖中間一層是“服務編排管理”，在傳統企業的SOA落地方案中，這是很重要的ESB（Enterprise Service Bus）模塊（服務的中心化調度模塊），而按照微服務理念設計的方案中則不會有這一層。

通過以上案例，你應該對企業應用架構有了進一步的感知。企業的各個軟件或產品并不是獨立的、割裂的，而是深度結合、互相支撐的。架構的理念在高階的B端產品設計中非常重要，同時B端產品的設計體系和技術架構也有著一脈相承的設計思路。理解技術架構對設計產品架構大有裨益。

插播一條廣告

大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。

我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。

幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。

掃碼即可報名，還可為大家爭取到的專屬優惠~

立即搶座，報名成功后即可領取詳細課程資料！

#專欄作家#

楊堃，公眾號：PM楊堃（ID：pmYangKun）。人人都是產品經理專欄作家，《決勝B端》作者，11年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司、百度，現就職于VIPKID。

本文原創發布于人人都是產品經理。未經作者許可，禁止轉載。

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