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框架實戰系列》，謝謝您的捧場。

目前視頻的源碼和附件都在QQ群里，如果需要源碼和文檔請加入QQ索取(996767213)。

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