其他系列博文
- 基于Abp的扩展模块实现第1例 - 数据权限控制（开发）
- 基于Abp的扩展模块实现第1例 - 数据权限控制（测试）
- 基于Abp的扩展模块实现第2例 - 数据字段按需更新（开发）
- 基于Abp的扩展模块实现第2例 - 数据字段按需更新（测试）
- 基于Abp的扩展模块实现第3例 - 状态管理（开发）
- 基于Abp的扩展模块实现第3例 - 状态管理（测试）
关于ABP Framework
ABP Framework 是一个遵循DDD实践的开源应用程序框架，专注于基于ASP.NET Core的Web应用程序开发，同时支持开发其他类型的应用程序，提供全栈的基础设施支持。该项目最早于2016年12月在 GitHub创建，截止本文发稿时已迭代至版本4.4.0-preview，收获6.3k个Star，在国内外.NET开发者中拥有较大知名度。
ABP Framework（为简洁起见，以下均以Abp代指ABP Framework，若遇ASP.NET Boilerplate则另行说明）通过对模块化的完整支持和基于DDD模式的分层设计，从架构分层和应用模块两个方向上进行了拆解和封装。相比更通用的仅对分层方向封装的做法，博主认为Abp的这种设计能更好地支持业务代码跨项目重用，且能更自然地实现微服务兼容。从另一个角度说，这也是种DRY的实践。
为什么要写这篇博文
当具备一定规模时，应用框架的通用性与易用性总是会存在设计上的冲突。Abp作为一个重型应用框架，在尽可能保证通用性和可扩展性的同时，也不可避免地在定制化上作了一定牺牲。虽然它提供了数十种强大的基础设施和预构建模块，但是面临数量繁多的业务类型，在实际工程中仍经常会面临自行实现基础模块的需要。在使用Abp开发的过程中，博主曾尝试延续Abp的代码风格，针对工作过程中遇到的业务类型去开发基于Abp的扩展项目，希望作为官方的一个分支项目。然而对于整个ASP.NET平台来说，目前非常需要一个完整的生产级解决方案来弥补生态系统的缺失，这个解决方案需要在基础设施、单机应用直至云原生构建上都能作为企业首选。不论Abp是否具备这样的可能性，博主认为轮子在质不在量，好的轮子出现时，需要社区开发者优先考虑参与迭代已有的项目，而不是另起炉灶，为定制化牺牲通用性。出于这点考虑，博主目前已逐渐减少分配在扩展项目上的精力，转而关注并参与对Abp官方项目的贡献。
与此同时，博主希望能在该系列博文中，把开发过程中的实践成果记录下来，为其他Abp开发者提供参考，开发者可自行决定直接使用或与社区分享。Abp作为.NET圈一个颇为年轻的产物，目前仍在快速迭代中，版本更替后更多预构建模块也在不停出现。受限于博文的时效性，博主使用的代码可能不适用于后续版本，设计的模块也可能后续由官方提供更好的实现。但是Abp的核心结构已经成型，模块的设计思路不会失效，博主希望能抛砖引玉，为其他开发者提供帮助。
P.S.
Abp提供了详尽的技术文档，并且由官方积极维护中。为了减少重复，该系列博文不会涉及Abp的基本使用。
受限于博主的技术水平，博文中的技术部分难免有不当之处，欢迎批评指正。
最后，希望Abp社区继续壮大，.NET技术越来越受欢迎。