浅谈Abp vNext的模块化设计

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的模块化设计

  • 原子封装,高度内聚——从设计原则看职责相对单一独立
  • 功能独立,职责单一——从设计原则看摆脱了耦合的风险
  • 随意组合,按需装配——从扩展来看十分灵活,容易维护
  • 独立开发,独立部署——从任务分解来看,分工非常容易
  • 面向接口,遵循约定——从框架设计来看,功底深厚
  • 极少修改,能力复用——从业务角度看,极大提高开发效率

  以上每一层都是层层递进,而最终的目的是为了达到企业级的能力复用,这和“高大上”的中台的意义不谋而合,不同的是粒度大小不同罢了。

  为了说的明白些,这里举一个例子:

  浅谈Abp vNext的模块化设计

   我们可以看到租户和用户模块可以和业务模块任意拼装,最后完成一个新的系统。

  • 如果你做的是2B的物业系统,你无需或者极少修改代码,就可以和组织管理进行组合成一个新的系统;
  • 如果你做的是2C的公众号,你又可以极速高效地和订餐系统组装成了另外一个系统。

   至此,你应该理解了模块化的价值和意义了?

模块化和DLL区别

  一般使用DLL的时候我们会先添加引用,然后直接调用,有时候还要增加默认配置。从这个角度看ABP的模块化应用是一样的,也需要增加Volo.Abp.*打头的DLL,同时依赖一些appsetting的配置。

  不同于DLL的地方在于继承AbpModule模块的类:

浅谈Abp vNext的模块化设计

  这个类的用途是做服务注册、配置或前后注册和配置的一些初始化工作。这是一个重大的不同,因为基于此,我们所有在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层:

浅谈Abp vNext的模块化设计

 

这个层的代码可以提前进行领域划分,但却是按照模块集成部署,微服务化后代码零变更。

    •  API Host层:

浅谈Abp vNext的模块化设计

 

服务拆分后这三个块的代码几乎是一模一样的。(具体可参看我的视频《ABP vNext框架实战系列》)

  • 共同复用原则(不强迫用户依赖他们不需要的东西)

浅谈Abp vNext的模块化设计
  如上所示,虽然Microsoft扩展配置模块是一体的,但是我们只要依赖Configuration.Abastraction即可。如果说共同闭包原则是做模块化内的加法,共同复用原则是做模块内容的减法,即把无需要依赖的内容剥离出去,让依赖更加纯净。

低耦合

  • 依赖于接口而非实现

  浅谈Abp vNext的模块化设计

 

   如上图所示,我们的租户依赖的除了租户接口以外,我们依赖的账户服务也是面向接口编程,这大大减少了服务之间的耦合,减少了拆分带来的巨大变更和代价。

  • 职责单一原则

  这个原则高度抽象和适用,ABP vNext也是处处体现这种思想,我们看下图官方模块源码的截图也能看到这个原则的落地运用。

  • 依赖反转原则

  依赖反转是一种设计思想,希望帮流程从运用中剥离出来,并把可复用的流程转移到框架之中,让框架具备能力复用的能力,从而依赖框架生产出无穷产品的能力。

 

官方模块源码

  从大的方面看,可以把abp的模块分为:

  • 应用模块,比如:博客、 文档、身份管理等等,如下图所示,可惜目前只有doc和blog属于免费的。

  浅谈Abp vNext的模块化设计

  • 框架模块,比如:缓存、邮件、主题、安全性、序列化、验证授权等等,如下图所示,每个模块的用途基本上是有迹可循的。

  浅谈Abp vNext的模块化设计

总结

  ABP vNext的模块化思想真的让人印象深刻,还有很多需要你我共同挖掘和学习的地方,我在这儿只是抛砖引玉,希望有更多的人能参与进来进行分享。如果你想了解更多ABP vNext的地方,你也可以参看我的视频《ABP vNext框架实战系列》,谢谢您的捧场。

  AbpvNext是一款优秀的框架,但是要从零开始能把每个角落都熟悉起来需要不少摸索时间,希望通过自己的经验给你的快速学习赋能,抛开生成器,一起从零开始,手工打磨一款生产级别的框架,让你对AbpvNext知其然,知其所以然。

 

上一篇:初识ABP vNext(5):ABP扩展实体


下一篇:初识ABP vNext(2):ABP启动模板