B端技術常識:軟件工程的“搭積木”設計
本文介紹了從技術架構視角來審視軟件體系是如何一步步發展演變,以及為什么說軟件工程就像是搭積木。
軟件工程是一項既復雜又簡單的系統性工程。說它復雜,是因為一整套良好運轉的體系是由數百萬行代碼構建而成的;說它簡單,是因為本質上軟件體系是無數組件化的小模塊拼裝而成的,每個研發人員或研發團隊只需要維護自己負責的組件與代碼模塊,復雜度會降低很多。
軟件的設計應該像搭積木那樣,通過自由拼接組裝來實現復雜的功能模塊,這樣既能保證系統的靈活性,又能避免重復開發,降低成本。如果不能將軟件分解成像積木那樣的小模塊,而是焊死的一塊鐵板,那么系統將徹底喪失靈活性。
軟件系統是如何像搭積木那樣拼接出復雜系統的呢?
我們以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協議。
如果軟件系統做得好,耦合度低,借口清晰,后續調整起來會比較好
有想去聽課的沖動
我們之前做項目就是由于模塊之間耦合度太高了,系統越來越不靈活
看堃哥的技術常識系列,突然覺得技術很有趣,打算去系統性學習一下
坐等下一篇,已關注
請問有沒有具體了解業務的辦法,感覺作者對業務的了解很透徹,對于產品來說,換了一個領域,業務盲點就是很大的困難
買了決勝B端
微服務架構中也有類似ESB的服務,注冊中心,API網關,其中的區別一直有些蒙