abp的模組化給我留下深刻的印象，模組化不是什麼新概念，大家都習以為常，但是為什麼要模組化，模組化的意義或者說目的是什麼？也許我們思考得並不深入。難得的是abp不僅完美的闡述了模組化概念，而且把模組化落地得十分優雅，並且進行了開源。
模組化內涵？
模組分類
根據粒度大小的不同，模組具有各自的概念，我們從小到大來看一下模組都有哪些內容。
- 零件——class（最小）
- 元件——component（較小），軟體的最小部署單元，比如jar，dll等
- 模組——module（更大），具有獨立名稱空間，可獨立開發、部署和測試，具備和其他模組組裝的能力，比如使用者管理模組、租戶模組等，在Abp vNext當初，一個模組就是一個專案。
- 微服務——microservice(最大)，比如工單服務，巡檢服務，保養服務等
Abp的模組是什麼
很多人對Abp vNext模組化的理解可能都不一樣，我理解的模組化至少應該包括以下一些內容：
- 部署上包括：柔性部署（包括獨立部署，也可整合部署）
模組化有什麼意義？
如果直接問你模組化的意義，可能你一下子還組織不好語言，因為無法用一句話來說明白。但是如果你想到樂高的存在，你一定會有所感悟。統一了模組化內涵，模組化的目的就十分明晰了。我們希望能像積木一樣複用我們的基礎能力，不管是架構能力還是應用能力，我們不想重複造輪子。
個人覺得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知其然，知其所以然。