ABP recall：ABP modularization

为什么recall，因为之前有个task涉及到项目的配置问题，完全不知道配置文件到底在干什么，重新结合 ABP的模块化理解一下。

之前对模块化的理解：结合ABP VNext来理解DDD_abp.vnext和abp哪个生产ddd_董厂长的博客-CSDN博客

再深入一些：为了柔性部署（包括独立部署，也可集成部署） 

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

 最能体会的应该是独立开发独立部署。

code example：

ABP项目中的program.cs文件是一个C#控制台应用程序的入口点。它包含一个静态的Main方法，该方法是应用程序的起始点。在ABP框架中，program.cs文件通常用于启动Web应用程序或后台服务。它可以配置应用程序的依赖注入容器、日志记录、数据库上下文等，并启动应用程序的主机。通过编辑program.cs文件，可以自定义应用程序的启动过程和配置。

随着项目的增长，配置文件下可能会增加很多配置 

 第一种想法，把相关的一系列配置抽象为静态方法，例如将所有swagger相关配置放到一个静态方法里面，想用的时候就调用。

缺点：需要注意 A配置可能在B配置之后，需要关注配置顺序。

进一步，抽成一个类库。项目A需要就引用绿色类库，项目B需要也可以引用绿色类库的方法。

缺点没变：需要关注配置顺序。

 ABP的做法：

 

 

 这两个方法和之前的静态方法的改造是一样的道理。给了两个拓展方法

把之前的demo改成拓展方法的形式，看上去就像ABP的progrma.cs：

简单理解是：接管了这个builder

再改造一下之前的demo：