Minimal Clean Architecture 单项目如何迁移为 Full Clean Architecture 多项目结构【免费下载链接】CleanArchitectureClean Architecture Solution Template: A proven Clean Architecture Template for ASP.NET Core 10项目地址: https://gitcode.com/GitHub_Trending/cl/CleanArchitecture如果你用 CleanArchitecture 模板的min-clean模板创建了 ASP.NET Core 项目——所有代码都在一个 Web 工程里按功能纵切Cart、Order、Product组织——而现在应用规模变大、出现多团队协作或者需要由编译器而不是约定来强制分层边界就可以按官方文档给出的迁移路径把单项目拆成 Core、UseCases、Infrastructure、Web 四个项目的 Full Clean Architecture 结构。下文的操作步骤来自 Minimal Clean Architecture 文档的 Migration Paths 一节目标结构与验证方式结合了 Getting Started、设计决策文档 和 MinimalClean/README.template.md。什么时候值得做这次迁移文档对两种模板的适用边界给了明确判断满足其中一条时单项目形式就不再合适Minimal 模板文档的 Not Recommended For 一节列出大型复杂领域应用需要大量 DDD 模式、需要严格边界的多个团队、预期长期演进的代码库、以及有严格审计/合规要求的场景——这些情况都直接给出结论 Use Full Clean Architecture instead。README.md 的模板对比表中Minimal 的 Migration Path 一栏写着 Can grow into full template文档同时建议拿不准时先用 Minimalmigrate to Full Clean Architecture if your application grows in complexity。ADR-001 说明了迁移换来的直接收益单项目下 Developers must respect folder boundaries (not enforced by compiler)、Harder to enforce strict layer separation拆成独立项目后引用关系由编译器和项目引用强制约束。目标结构代码该进哪个项目迁移完成后解决方案应形成 design-decisions.md 描述的四个职责项目项目存放内容依赖规则Core实体、聚合、值对象、领域事件与处理器、领域服务、Specifications、接口、DTO有时外部依赖最少all other project dependencies should point toward itUseCases按 CQRS 组织的 Commands 与 QueriesCommands 通过 Repository 抽象访问数据Queries 可直接用查询服务依赖 Core不依赖 InfrastructureInfrastructure外部资源依赖数据访问、邮件等的实现类实现 Core 中定义的接口依赖 CoreWeb应用入口、FastEndpoints 端点及其请求/响应类型REPR 模式按需要引用 UseCases 或 InfrastructureMinimalClean/README.template.md 给出的整体依赖方向是Core ← UseCases ← Infrastructure即所有依赖指向 Core。对照单项目里的现有代码去向如下Web 工程的Domain/文件夹Cart、Order、Product 等聚合→ CoreWeb 工程的Infrastructure/文件夹AppDbContext、EF 配置、Migrations、Email 等→ Infrastructure端点中的业务逻辑如果已使用 Mediator 的处理器也一并归入→ UseCases可选FastEndpoints 端点与Program.cs启动代码 → 留在 Web执行步骤逐个抽出三个项目下面的命令块均按源文档原文保留。其中的YourProject是文档使用的项目名前缀占位符需替换为你自己的解决方案项目名例如基于 minimal 模板生成的MinimalClean.Architecture。mv命令的执行前提是先在解决方案根目录用dotnet new创建新项目然后到 Web 工程目录下执行移动。步骤 1抽取 Core 项目# Create new Core project dotnet new classlib -n YourProject.Core # Move domain entities mv Domain/* ../YourProject.Core/ # Update namespaces # Update project references把 Web 工程Domain/下的全部文件移入新的 Core 项目后更新这些文件的命名空间并在 Web 工程中增加对 Core 的引用。步骤 2抽取 Infrastructure 项目# Create Infrastructure project dotnet new classlib -n YourProject.Infrastructure # Move infrastructure code mv Infrastructure/* ../YourProject.Infrastructure/ # Add reference to Core dotnet add YourProject.Infrastructure reference YourProject.CoreEF Core 的AppDbContext、Data/Config下的配置类和Migrations文件夹都随 Infrastructure 代码一起移走。这一点会直接影响后续迁移命令的执行方式见后文的数据库部分。步骤 3可选抽取 UseCases 项目文档明确将这一步标注为 Optional。只有当你希望把业务逻辑从端点中移出、或需要 Mediator pipeline behaviors 处理横切关注点时才做# Create UseCases project dotnet new classlib -n YourProject.UseCases # Move business logic from endpoints to use cases # Add Mediator (if not already using) # Create command/query handlers # Leverage Mediator Behaviors for cross-cutting concerns注意 Minimal 模板的 ADR-004 表明 Mediator 本来就是可选的简单 CRUD 可以把逻辑直接放在端点里。如果你此前没有使用 Mediator注释中的 Add Mediator (if not already using) 意味着这一步同时要把 Mediator 引入项目再创建 command/query handlers。步骤 4清理 Web 项目文档给出的收尾动作有三条Update project references更新项目引用Keep only endpoints and startup code只保留端点和启动代码Reference UseCases or Infrastructure as needed按需要引用 UseCases 或 Infrastructure完成后Web 工程只剩 FastEndpoints 端点含各自的请求/响应类型与启动代码这正是 Full 模板对 The Web Project 的职责描述。可选分支用完整模板生成参考方案核对结构docs/content/migration-guides/v10-to-v11.md 针对模板版本升级给出的 Diff strategy 是先用新版模板生成一套全新解决方案再用 diff 工具Beyond Compare、WinMerge 或git diff对比最后手工套用结构性与包版本变化。同样的做法可以借用来核对结构迁移的产物——在当前目录生成一套 Full 模板方案与迁移后的项目对比确认项目引用、命名空间布局与模板目标形态一致dotnet new clean-arch -o Your.ProjectName生成项目名有两个已知问题来自 Getting Started 文档名字中不要带连字符不要用Ardalis作为命名空间会与依赖冲突。验证与迁移后的数据库操作Full Clean Architecture 生成方案的 Getting Started见 README.template.md给出标准验证顺序# Build the solution dotnet build # Run the application dotnet run --project src/Your.ProjectName.Web构建通过、Web 工程能正常启动说明结构迁移在代码层面完成。迁移后有一个必须验证的变化点EF Core 命令。单项目形式下 DbContext 就在 Web 工程里dotnet ef命令无需额外指定项目Infrastructure 工程拆分出去之后命令必须同时指定目标项目和启动项目。docs/content/getting-started.md 的 Running Migrations 一节给出 Full 模板下的形式原文示例使用Clean.Architecture前缀并明确提示要替换成你自己的项目名dotnet ef database update -c AppDbContext -p ../Your.ProjectName.Infrastructure/Your.ProjectName.Infrastructure.csproj -s Your.ProjectName.Web.csproj新增迁移同理CLI 形式从 Web 工程目录执行dotnet ef migrations add MIGRATIONNAME -c AppDbContext -p ../Your.ProjectName.Infrastructure/Your.ProjectName.Infrastructure.csproj -s Your.ProjectName.Web.csproj -o Data/Migrations在 Visual Studio 中则通过 Package Manager Console 执行Add-Migration InitialMigrationName -StartupProject Your.ProjectName.Web -Context AppDbContext -Project Your.ProjectName.Infrastructure。限制与边界文档提供的迁移路径是手工操作mv移动文件、更新命名空间、更新项目引用都需要自行完成文档没有提供自动化工具。步骤 3 是可选的跳过它时Web 工程保持对 Infrastructure 的直接引用即可但端点内的业务逻辑就不会获得独立项目和 pipeline 能力。如果迁移后觉得完整模板过于复杂文档同时提供了反向路径From Full Clean Architecture to Minimal把项目合并回 Web、用 LINQ 替换 Specifications、按功能纵切重新组织文件夹。【免费下载链接】CleanArchitectureClean Architecture Solution Template: A proven Clean Architecture Template for ASP.NET Core 10项目地址: https://gitcode.com/GitHub_Trending/cl/CleanArchitecture创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考