淺談Abp vNext的模組化設計

張飛洪[廈門]發表於2020-12-02

abp的模組化給我留下深刻的印象,模組化不是什麼新概念,大家都習以為常,但是為什麼要模組化,模組化的意義或者說目的是什麼?也許我們思考得並不深入。難得的是abp不僅完美的闡述了模組化概念,而且把模組化落地得十分優雅,並且進行了開源。

模組化內涵?

模組分類

  根據粒度大小的不同,模組具有各自的概念,我們從小到大來看一下模組都有哪些內容。

  • 零件——class(最小)
  • 元件——component(較小),軟體的最小部署單元,比如jar,dll等
  • 模組——module(更大),具有獨立名稱空間,可獨立開發、部署和測試,具備和其他模組組裝的能力,比如使用者管理模組、租戶模組等,在Abp vNext當初,一個模組就是一個專案。
  • 微服務——microservice(最大),比如工單服務,巡檢服務,保養服務等

  淺談Abp vNext的模組化設計

Abp的模組是什麼

  很多人對Abp vNext模組化的理解可能都不一樣,我理解的模組化至少應該包括以下一些內容:

  • 廣義上包括:實體、服務、APIs、UI頁面、資料庫
  • 應用上包括:賬號管理、身份管理、租戶管理、設定管理、許可權管理…
  • 部署上包括:柔性部署(包括獨立部署,也可整合部署)
  • 能力上包括:服務任意拼裝、組合
  • 技術上依託:反射、配置、工廠、注入、動態代理等底層技術
  • 模組劃分姿勢:類微服務,縱向,橫向,部署便捷,維護成本

  從Abp vNext的開原始碼和demo裡,我們隨處可以看到module這個單詞,而且一旦我們的project繼承abpModule後,依賴abp底層的注入能力,我們即刻給專案賦予了模組化能力,同時,藉助自動controller和動態代理的能力,模組之間通訊只需要簡單配置即可。可以說沒有以上兩種能力,模組化的落地也就無從談起了。

模組化有什麼意義?

  統一了模組化內涵,模組化的目的就十分明晰了。我們希望能像積木一樣複用我們的基礎能力,不管是架構能力還是應用能力,我們不想重複造輪子。

  如果直接問你模組化的意義,可能你一下子還組織不好語言,因為無法用一句話來說明白。但是如果你想到樂高的存在,你一定會有所感悟。個人覺得Abp vNext的模組化背後有著豐富的內涵。通讀abp的官方文件,對模組化的理解更加全面些,個人理解,abp的模組化至少包含以下幾層含義:

       淺談Abp vNext的模組化設計

  • 原子封裝,高度內聚——從設計原則看職責相對單一獨立
  • 功能獨立,職責單一——從設計原則看擺脫了耦合的風險
  • 隨意組合,按需裝配——從擴充套件來看十分靈活,容易維護
  • 獨立開發,獨立部署——從任務分解來看,分工非常容易
  • 面向介面,遵循約定——從框架設計來看,功底深厚
  • 極少修改,能力複用——從業務角度看,極大提高開發效率

  以上每一層都是層層遞進,而最終的目的是為了達到企業級的能力複用,這和“高大上”的中臺的意義不謀而合,不同的是粒度大小不同罷了。

  為了說的明白些,這裡舉一個例子:

  

   我們可以看到租戶和使用者模組可以和業務模組任意拼裝,最後完成一個新的系統。

  • 如果你做的是2B的物業系統,你無需或者極少修改程式碼,就可以和組織管理進行組合成一個新的系統;
  • 如果你做的是2C的公眾號,你又可以極速高效地和訂餐系統組裝成了另外一個系統。

   至此,你應該理解了模組化的價值和意義了?

模組化和DLL區別

  一般使用DLL的時候我們會先新增引用,然後直接呼叫,有時候還要增加預設配置。從這個角度看ABP的模組化應用是一樣的,也需要增加Volo.Abp.*打頭的DLL,同時依賴一些appsetting的配置。

  不同於DLL的地方在於繼承AbpModule模組的類:

  這個類的用途是做服務註冊、配置或前後註冊和配置的一些初始化工作。這是一個重大的不同,因為基於此,我們所有在ABP模組化的基礎上都可以互相拼裝,不管是基礎框架還是應用框架。拼裝後的專案具備了一種新的能力或者可以單獨分散式部署,這是DLL做不到。

  舉個例子,加入我們想在BookStore專案上整合Account/PermissionManage/TenantManage/Identity等服務,我們會怎麼做?有兩種方式,一種是單體,直接進行DependOn就整合了,中間是低程式碼的組裝,而DLL的傳統做法是做不到的,因為它只是一個類庫,需要引用後整合編碼,程式碼量是嵌入或者說是織入而成,是主程式碼的一個零部件,非常難以解耦。另外一種是分散式微服務部署,我們可以把Account/Permission/Identity進行獨立部署,其他專案想要進行整合也沒有問題,採用微服務方式進行互動或者單點登入。所有ABP vNext的模組化是微服務相容的,從這個級別上看二則不可同日而語。

模組化拆分原則

高內聚

  • 複用/釋出等同原則(複用的最小粒度等同於釋出的最小粒度)

  這點在ABP vNext上可以很明顯得看到,所有繼承AbpModule的模組都是可以獨立部署的,不管是一個Project或者Class都是支援的。

  • 共同閉包原則(一個元件不該存在多個變更原因:會同時修改的類放在一個元件中)

  我們在做微服務演化和領域拆分的時候,這個原則是非常受用的。比如我們可以先把Tenant.Application和Account.Application按照介面和模組化進行提前拆分,通過ApiHost彙總單塊部署,當我們需要進行拆分的時候,我們只需要對ApiHost進行一分為二即可,這個拆分是低程式碼的。如下圖所示:

    • Application層:

 

這個層的程式碼可以提前進行領域劃分,但卻是按照模組整合部署,微服務化後程式碼零變更。

    •  API Host層:

 

服務拆分後這三個塊的程式碼幾乎是一模一樣的。(具體可參看我的視訊《ABP vNext框架實戰系列》)

  • 共同複用原則(不強迫使用者依賴他們不需要的東西)

淺談Abp vNext的模組化設計
  如上所示,雖然Microsoft擴充套件配置模組是一體的,但是我們只要依賴Configuration.Abastraction即可。如果說共同閉包原則是做模組化內的加法,共同複用原則是做模組內容的減法,即把無需要依賴的內容剝離出去,讓依賴更加純淨。

低耦合

  • 依賴於介面而非實現

  

 

   如上圖所示,我們的租戶依賴的除了租戶介面以外,我們依賴的賬戶服務也是面向介面程式設計,這大大減少了服務之間的耦合,減少了拆分帶來的巨大變更和代價。

  • 職責單一原則

  這個原則高度抽象和適用,ABP vNext也是處處體現這種思想,我們看下圖官方模組原始碼的截圖也能看到這個原則的落地運用。

  • 依賴反轉原則

  依賴反轉是一種設計思想,希望幫流程從運用中剝離出來,並把可複用的流程轉移到框架之中,讓框架具備能力複用的能力,從而依賴框架生產出無窮產品的能力。

 

官方模組原始碼

  從大的方面看,可以把abp的模組分為:

  • 應用模組,比如:部落格、 文件、身份管理等等,如下圖所示,可惜目前只有doc和blog屬於免費的。

  淺談Abp vNext的模組化設計

  • 框架模組,比如:快取、郵件、主題、安全性、序列化、驗證授權等等,如下圖所示,每個模組的用途基本上是有跡可循的。

  

總結

  ABP vNext的模組化思想真的讓人印象深刻,還有很多需要你我共同挖掘和學習的地方,我在這兒只是拋磚引玉,希望有更多的人能參與進來進行分享。如果你想了解更多ABP vNext的地方,你也可以參看我的視訊《ABP vNext框架實戰系列》,謝謝您的捧場。

  AbpvNext是一款優秀的框架,但是要從零開始能把每個角落都熟悉起來需要不少摸索時間,希望通過自己的經驗給你的快速學習賦能,拋開生成器,一起從零開始,手工打磨一款生產級別的框架,讓你對AbpvNext知其然,知其所以然。

 

相關文章