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

軟件工程是一項既復(fù)雜又簡單的系統(tǒng)性工程。說它復(fù)雜，是因為一整套良好運轉(zhuǎn)的體系是由數(shù)百萬行代碼構(gòu)建而成的；說它簡單，是因為本質(zhì)上軟件體系是無數(shù)組件化的小模塊拼裝而成的，每個研發(fā)人員或研發(fā)團(tuán)隊只需要維護(hù)自己負(fù)責(zé)的組件與代碼模塊，復(fù)雜度會降低很多。

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

軟件系統(tǒng)是如何像搭積木那樣拼接出復(fù)雜系統(tǒng)的呢？

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

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

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

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

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

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

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

接下來，業(yè)務(wù)發(fā)展對Passport系統(tǒng)提出了新的需求：

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

因為此時Passport系統(tǒng)已經(jīng)高度抽象和服務(wù)化，具備強大的平臺能力，這些個性化訴求所需的后端功能接口都已成熟，所以業(yè)務(wù)系統(tǒng)只需要簡單地開發(fā)前端模塊并調(diào)用后端服務(wù)，就可以滿足各種個性化要求，系統(tǒng)的結(jié)構(gòu)非常靈活，如下圖所示：

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

在第5章針對M公司分銷平臺的應(yīng)用架構(gòu)設(shè)計中，我們提到M公司各個系統(tǒng)已經(jīng)實現(xiàn)了服務(wù)化，因此分銷平臺的很多功能模塊都可以復(fù)用現(xiàn)有系統(tǒng)，例如分銷平臺復(fù)用了客戶主數(shù)據(jù)系統(tǒng)、Passport系統(tǒng)、支付（Pay）系統(tǒng)、權(quán)限管理（Auth）系統(tǒng)、訂單中心、倉儲服務(wù)系統(tǒng)等。

這些被復(fù)用的系統(tǒng)（主要提供各種功能接口）就像一個個積木塊，重新搭配組合，支撐了分銷平臺的業(yè)務(wù)。上面的應(yīng)用架構(gòu)圖在一定程度上體現(xiàn)了這種復(fù)用關(guān)系，我們從技術(shù)視角繪制出技術(shù)架構(gòu)圖，如下圖所示，讀者能夠從這幅圖中更清晰地感受“搭積木”的設(shè)計結(jié)構(gòu)。

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

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

插播一條廣告

大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產(chǎn)品總監(jiān)一職。在工作中，遇見有很多優(yōu)秀的B端產(chǎn)品經(jīng)理，但缺少體系化、針對B端產(chǎn)品的實操訓(xùn)練，在成長中走了許多彎路。

我努力將自己多年做B端產(chǎn)品的經(jīng)驗提煉總結(jié)出來，和起點學(xué)院聯(lián)合打造了一門B端產(chǎn)品體系課——《To B產(chǎn)品實戰(zhàn)訓(xùn)練營》希望能給需要的同學(xué)一些實質(zhì)性的幫助。

幫助大家構(gòu)建B端產(chǎn)品知識體系脈絡(luò)，掌握B端產(chǎn)品建設(shè)，從業(yè)務(wù)診斷、需求分析，到抽象建模、設(shè)計落地的全過程的方法思路，最終直接應(yīng)用于工作實踐。

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

立即搶座，報名成功后即可領(lǐng)取詳細(xì)課程資料！

#專欄作家#

楊堃，公眾號：PM楊堃（ID：pmYangKun）。人人都是產(chǎn)品經(jīng)理專欄作家，《決勝B端》作者，11年互聯(lián)網(wǎng)研發(fā)、產(chǎn)品設(shè)計經(jīng)驗，曾就職于傳統(tǒng)外資保險公司、百度，現(xiàn)就職于VIPKID。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。