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知其然，知其所以然。