首先这里会移除掉 .IdentityServer 这个 Web 项目以及目前使用不到的 test 文件夹，从上面运行的 swagger 页面中就可以看到，初始化的模板中包含了一些业务功能开发中可能用不到的功能，而这些功能则是包含在项目所引用的 ABP 类库中的。因此，对于模板功能的精简则是将引用的一些用不到的 Volo.Abp.* 类库进行去除，仅保留我们所需的部分
这里我移除了下列的程序集引用，重新编译解决方案，不出意外会报很多的错误，因为具体的排错过程会涉及到很多，不太好用文字进行描述，所以这里就跳过了
Volo.Abp.Account.*
Volo.Abp.Identity.*
Volo.Abp.IdentityServer.*
Volo.Abp.PermissionManagement.*
Volo.Abp.TenantManagement.*
Volo.Abp.FeatureManagement.*
Volo.Abp.SettingManagement.*
Volo.Abp.AspNetCore.Mvc.UI.MultiTenancy
这里对于模板项目中的功能基本上都移除了，只保留了 audit 日志、后台任务、邮件通知、对象映射、EF Core 这类的基础服务
总结来说，对于移除功能后导致的编译报错，只需要将相关的类文件、引用直接删除就好，而对于功能移除之后产生的代码问题，就需要具体分析了，这类的问题基本上是初始化数据（DataSeed）的功能，我这边采取的是直接移除相关的功能
至此，当你进行到这一步时，也就可以顺势将 .DbMigrator 这个专门用于数据库迁移的控制台应用进行移除了，而对于迁移的这个功能，在下面的内容中我也将补充到别的类库上
哦对了，在移除上面的功能之后，你还需要在如下的类库中添加对应的 ABP 程序集引用，从而确保程序可以编译通过
.Application 引用 Volo.Abp.Ddd.Application
.Domain.Shared 引用 Volo.Abp.Validation
.HttpApi 引用 Volo.Abp.AspNetCore.Mvc
.HttpApi.Client 引用 Volo.Abp.Http.Client
如果不出意外的话，你的应用已经能够编译成功，并且可以再次运行了，从 swagger 也就可以看出，整个模板去掉了绝大多数的功能。当然，如果你觉得这个过程比较麻烦的话，也可以直接使用文章开头所列到的 github 的项目，然后在上面基于你的需求进行调整即可
让我们再回到最原始的后端模板项目中，整个后端解决方案的项目全局结构如下所示
因为移除了单元测试的相关类库，从项目依赖关系图中就可以看到，整个解决方案中，包含了三个最顶层的项目，.IdentityServer、.HttpApi.Host、.DbMigrator，其它类库之间通过相互引用，构建出项目的分层基础
当然，在上面进行模板功能的精简时，已经将 .IdentityServer、.DbMigrator 这一块进行了整体的移除
2.3.1、合并 EntityFramework Core 相关功能类库因为这里选择了 EntityFramework Core（以下简称 EF Core）作为项目的 ORM，如果使用 Code First 模式的话，不可避免的会使用到 migrations 这样一个迁移的操作，在原始的模板中，存在着如下的三个类库与之存在关联
.DbMigrator：控制台程序，主要是为了进行数据库的迁移工作（migration）
.EntityFrameworkCore：集成 EF Core 到项目中，定义 DbContext 和领域中的数据访问仓储（Repository），在整个项目中提供数据持久化以及数据访问
.EntityFrameworkCore.DbMigrations：执行 EF Core 的迁移
可以看到，ABP 作为一个模块化的框架，对于每个类库的使用用途定义的非常清楚，但是，在实际的开发中，对于正式环境数据库的操作基本上都是交由 DBA 来执行的，EF Core 的 migration 更多的是在开发时进行使用。同时，如果真的这样划分的话，至少我遇到的绝大多数开发人员都是会叫的
介于上面已经将 .DbMigrator 进行了移除，因此，这里将对于 EF Core 的相关操作全部合并到 .EntityFrameworkCore 这个类库中