淺談Abp vNext的模塊化設計

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

模塊化內涵?

模塊分類

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

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

  

Abp的模塊是什麼

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

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

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

模塊化有什麼意義?

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

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

       

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

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

  爲了說的明白些,這裏舉一個例子:

  

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

  • 如果你做的是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框架實戰系列》)

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


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

低耦合

  • 依賴於接口而非實現

  

 

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

  • 職責單一原則

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

  • 依賴反轉原則

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

 

官方模塊源碼

  從大的方面看,可以把abp的模塊分爲:

  • 應用模塊,比如:博客、 文檔、身份管理等等,如下圖所示,可惜目前只有doc和blog屬於免費的。

  

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

  

總結

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

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

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章