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"；文档同时建议：拿不准时先用 Minimal，"migrate 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 it" |
| UseCases | 按 CQRS 组织的 Commands 与 Queries；Commands 通过 Repository 抽象访问数据，Queries 可直接用查询服务 | 依赖 Core，不依赖 Infrastructure |
| Infrastructure | 外部资源依赖（数据访问、邮件等）的实现类，实现 Core 中定义的接口 | 依赖 Core |
| Web | 应用入口、FastEndpoints 端点及其请求/响应类型（REPR 模式） | 按需要引用 UseCases 或 Infrastructure |
MinimalClean/README.template.md 给出的整体依赖方向是Core ← UseCases ← Infrastructure，即所有依赖指向 Core。对照单项目里的现有代码，去向如下：
- Web 工程的
Domain/文件夹（Cart、Order、Product 等聚合）→ Core - Web 工程的
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），仅供参考
