聊聊 ASP.NET 6 整洁架构开发模板

阅读原文时间：2023年08月09日阅读：3

大家好，我是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项目。