聊聊 ASP.NET 6 整洁架构开发模板
最近看了一些整洁架构（CleanArchitecture）的文章，自己和同事也简单写了一个基于整洁架构的ASP.NET 6开发模板在玩。这里就仅仅抛个砖，案例主要以自己根据小组实际情况做了一些裁剪，可能不具有通用的应用性，大家看看就好。
大家好，我是Edison。
最近看了一些整洁架构（CleanArchitecture）的文章，自己和同事也简单写了一个基于整洁架构的ASP.NET 6开发模板在玩。这里就仅仅抛个砖，案例主要以自己根据小组实际情况做了一些裁剪，可能不具有通用的应用性，大家看看就好。
整洁架构的产生背景
微服务架构让DDD（领域驱动设计）焕发了第二春，在DDD的推动下，DDD的分层架构被逐渐推上了舞台。DDD的分层架构就有好多种，例如整洁架构、CQRS和六边形架构等等，每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，从而能够实现架构的演进。
DDD分层架构
在欧创新老师的《DDD实战课》中，给出了一个优化后的DDD四层架构，我们可以从下面这张图中看到，从上到下分别是：用户接口层、应用层、领域层和基础层。
与传统的三层架构不同，DDD四层架构的重点在于引入了一个领域层。
领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。领域层包含：聚合根、实体、值对象、领域服务等领域模型中的领域对象。对于领域层，领域模型的业务逻辑主要由实体和领域服务来实现。对于实体，一般建议采用充血模型来实现所有与之相关的业务功能。对于领域服务，一般当单个实体不能实现某些功能时，领域服务才会出马，组合聚合内的多个实体来实现复杂的业务逻辑。下图中展示了传统的三层架构与DDD四层架构的对应关系：
整洁架构简单介绍
简而言之，整洁架构是组织软件体系结构的原则，可以轻松面对未来的不确定性，方便代码的重构。同时，它可以帮助我们为特定的领域模型构建服务，从而为将来可能的微服务体系结构做好准备。在Jason Taylor的这篇文章中《Clean Architecture with .NET Core: Gettting Started》中给出了一张经典的图：
在整洁架构中，所有依赖关系都向内流动，而核心层不依赖于其他任何层。基础设施层和展示层依赖于核心层，而不是彼此依赖。在Jason Taylor给出的图中，只有三个圆圈，但在实际中，你可能需要更多，但是你可以以此作为起点，只需要记住让所有依赖都指向内部即可。这里的内部，我们可以将其称为ApplicationCore，也就是Application + Domain。
整洁架构模板搭建
这里我试着搭建了一个基于ASP.NET 6的开发模板，展示层有两种可选：ASP.NET WebAPI / Blazor。需要说明是：该模板仅仅是结合我司实际情况的构想，没有遵循DDD的一些原则思想（DDD是个好东西，但不是所有项目都适用，也不是所有团队都可以用好），也不具有广泛应用性，各位看官看看一笑而过就好。
在我司（一家制造业工厂的IT部），基于我们组的实际人员情况中（开发基础能力较弱，以前的工作基本以运维为主，很少做开发工作）和开发项目的综合复杂度（严格来说，复杂度并不高，以后台管理信息系统为主），我不想引入太多DDD的概念增加学习成本，因此ValueObject和Domain Service被我移除了，但是充血模型的Entity是我们所倡导的，因此，最终的结构如下图所示：
对于展示层，分别使用WebAPI和Blazor实现API和UI的宿主；
对于核心层（ApplicationCore），包含 Application 和 Domain 两个.NET 6.0类库项目。
（1）Application定义了Services、Handlers（对于MQ的Consumers）、Validators（基于FluentValidation的Validators）以及 各种Models（DTO、VO，以及基于AutoMapper的MappingProfiles）。
（2）Domain则定义了实体、枚举、异常、常量等。这一层无需引入过多概念，只需要在原有实体的基础上，使用充血模型，让实体的行为丰富起来即可，这也可以让开发人员很快适应和模仿。
对于基础设施层，也是一个.NET 6.0类库，主要包含了基于EF Core的上下文（DbContext）、实体映射关系（EntityConfiguration）、Repositories、Gateways（针对依赖的外部接口HttpClient实现，可以用HttpClientFactory来实现，也可以用WebApiClient之类的封装项目）、Cache（比如RedisClient的注册）、MessageQueue（比如KafkaClient的注册，取决于你们组用了什么MQ）等。
除了上面的四层之外，设计一个CrossCuting的Shared类库，用于存放一些各个层都可以复用（引用）的帮助类、扩展方法、基类等，用于减少重复。整个项目在Visual Studio中的解决方案目录如下图所示：
整个项目在Visual Studio中的解决方案目录如下图所示：
最终的依赖关系如下：
（1）Domain类库只引用Shared类库（即CrossCutting）。
（2）Application类库引用：Domain、Infrastructure、Shared
这里我们没有让Application不依赖于Infrastructure，是因为我们的DB技术栈已经固定，而且大家也比较习惯于在Infrastructure里边定义Repository、Gateway等的interface，而不是在Application里面定义这些interface，Infrastructure通过应用Application来做实现。
（3）Infrastructure类库引用：Domain、Shared
（4）Web项目引用：Application、Shared（其实这里Application引用了Shared，Web项目无需再添加引用）
（5）WebUI项目引用：Application、Shared（其实这里Application引用了Shared，Web项目无需再添加引用）通常情况下，WebAPI和WebUI项目二者只选选择一个，因此新项目创建好之后，删除其中一个。
（6）Application.UnitTests项目引用：Application
（7）Domain.UnitTests项目引用：Domain
（8）Web.IntegrationTests项目引用：Web
在实际模板中，针对ServiceCollection和ApplicationBuilder写了很多扩展方法，用于一些常见组件的注册，例如Swagger、CAP（Event Bus）、Redis Client、健康检查EndPoints、KeyCloak鉴权启用等等。开发者只需要根据需要在配置文件中添加或移除对应部分的config即可，这些扩展方法会根据配置文件中是否有这部分的config来判断是否需要注册。因此，大部分情况下，小组的开发者要做的仅仅是做减法。比如，如果项目只用到了Cache没有用到EventBus，那么只需要在配置中移除EventBus的部分即可，不用改任何一句代码。又如，通常大部分项目里我们只会保留一个UnitTest类库，而不是让三个都在项目中，因为我们的精力不足以写三种类型的Test项目。但是某些大一点的项目，对质量有要求的，我们可能会写两中类型的Test项目。
模板上传Nuget仓库
这里我们主要通过将其发布为一个Nuget包上传到企业内部的Nuget仓库，然后客户端可以通过安装这个nuget包将其添加到Visual Studio中的项目模板中。
当然，也可以直接通过dotnet new命令直接通过模板创建新项目。
-- install dotnet new install CleanArchitectureTemplate -- uninstall dotnet new uninstall CleanArchitectureTemplate
同理，当将开发模板发布了新的nuget包，客户端也可以通过更新nuget包的方式将模板进行更新，以便下次可以使用新的模板进行项目的开发。
-- check dotnet new --update-check -- apply dotnet new --update-apply
关于如何通过Nuget上传开发模板，可以参考Microsoft的这一篇文档：https://learn.microsoft.com/zh-cn/dotnet/core/tools/custom-templates
小结
本文介绍了DDD分层架构的背景、整洁架构的概念，随后分享了一个基于我所在小组的实际情况的一个整洁架构的模板案例。在实际情况中，ABP vNext也是一不错的选择，对DDD有兴趣应用的建议仔细看看。
参考代码
GitHub：https://github.com/EdisonChou/CleanArchitectureTemplate
参考资料
Jason Taylor，《Clean Architecture with .NET Core: Gettting Started》
欧创新，极客时间《DDD实战课》
Jacky Fei，《基于ASP.NET 6的整洁架构》
Alexander Zhao，《.NET Core整洁架构入门》
Denny Zhang，《领域驱动架构及其演变历史》
