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

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

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

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

　　我們以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端産品的設計體系和技術架構也有着一脈相承的設計思路。理解技術架構對設計産品架構大有裨益。

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

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

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

　　,