在 .NET 新项目或重构时如何选择合适架构（VSA/Cle…

当用户询问「用哪种架构」「如何组织项目」「新项目搭建」「架构决策」「重构」时，先做结构化问卷再推荐最合适的 .NET 架构。

适用场景

解决思路

1. 先问再推荐：在了解项目之前绝不直接指定架构，先运行问卷收集领域、团队、生命周期和约束等上下文。
2. 按实际复杂度选择架构：最好的架构是能处理项目真实复杂度的最简架构；CRUD 应用不需要 DDD，初创项目不需要 Clean Architecture，让复杂度匹配真实需求而非愿景。
3. 把架构视为可演进而非永久：每个架构都有演进路径，从简单开始，当复杂度需要时再增加结构，并记录决策以便团队知道何时演进。
4. 只支持四种架构：Vertical Slice Architecture (VSA)、Clean Architecture (CA)、DDD + Clean Architecture、Modular Monolith，各有优劣。
5. 运行 6 类问卷（可跳过不相关问题）：① 领域复杂度——实体数量（<10 低 / 20+ 且有关系为高）、业务规则是否跨实体交互（按实体 CRUD 为低 / 跨实体组复杂不变量为高）、是否有多个步骤的业务工作流（简单请求-响应为低 / Saga、审批链、状态机为高）、领域专家是否使用专门术语（通用术语为低 / 通用语言如 underwrite、adjudicate 为高）。
6. ② 团队与组织——团队规模（1-3 人为低 / 8+ 人且多团队为高）、不同团队是否负责不同部分（单团队为低 / 按业务领域对齐团队为高）、团队 .NET 经验（初级或混合为低 / 资深且熟悉模式为高）。
7. ③ 系统生命周期与规模——预期生命周期（<2 年 MVP/原型为低 / 5+ 年长期产品为高）、并发用户或 RPS（<100 RPS 为低 / 1000+ RPS 且负载波动为高）、是否需要按功能区域独立扩展（负载均匀为低 / 热点需独立扩展为高）。
8. ④ 监管与合规——是否有审计或合规要求（基本日志为低 / 完整审计、SOX/HIPAA/PCI 为高）、不同部分是否有不同安全边界（单一认证边界为低 / 多租户、数据隔离为高）。
9. ⑤ 现有代码库——绿地还是棕地（全新为绿地 / 从遗留系统迁移为棕地）、团队是否已有架构模式（无既定模式为低 / 有强约定为高）。
10. ⑥ 集成复杂度——集成多少外部系统（0-2 个简单 API 为低 / 5+ 个复杂契约为高）、是否需要事件驱动或异步通信（同步请求-响应为低 / 事件溯源、pub/sub、最终一致性为高）。
11. 按决策矩阵映射推荐：低领域复杂度+小团队+短生命周期 → VSA；低-中领域复杂度+任意团队+API 导向 → VSA；中领域复杂度+中团队+长生命周期 → Clean Architecture；高领域复杂度+专门术语+复杂不变量 → DDD + Clean Architecture；多限界上下文+按领域分团队+可独立部署 → Modular Monolith；棕地且已有分层架构 → Clean Architecture。
12. 信号冲突时按优先级处理：① 默认选更简单的，存疑时先用 VSA 再演进；② 领域复杂度优先，高领域复杂度覆盖团队规模和生命周期信号；③ 团队熟悉度重要，熟悉 CA 的团队用 CA 比学 VSA 更高效；④ 合规驱动结构，监管要求常强制更严格边界（CA 或 DDD）。
13. VSA 落地：按功能而非分层组织，每个操作是自包含切片，如 Features/Orders/CreateOrder.cs 内含 Request + Handler + Response + Endpoint，适用于 CRUD 密集、API、MVP、中小团队、中短生命周期，加载 skill `vertical-slice`。
14. Clean Architecture 落地：同心层加依赖倒置，Domain 在中心、Infrastructure 在边缘，项目结构为 MyApp.Domain / MyApp.Application / MyApp.Infrastructure / MyApp.Api，适用于中等复杂度、长期系统、熟悉分层模式的团队，加载 skill `clean-architecture`。
15. DDD + Clean Architecture 落地：在 Clean Architecture 上加入战术 DDD 模式（聚合、值对象、领域事件），Domain 含聚合/值对象/领域事件/领域服务，Application 编排聚合，Api 保持薄，适用于复杂领域、专门术语、严格不变量、资深团队，加载 skill `ddd` + `clean-architecture`。
16. Modular Monolith 落地：单一可部署单元内的独立模块，每个模块内部可用自己的架构，结构为 MyApp.Host 负责接线、Modules/Orders 与 Modules/Catalog 各自拥有功能/DbContext/架构、MyApp.Shared 仅放集成事件契约，适用于多限界上下文、按领域分团队、未来拆微服务，加载模板 `modular-monolith`。
17. 按演进路径迁移：VSA → CA（领域逻辑超出 handler 时，抽取 Domain + Application 层，保留功能作为用例）；VSA → Modular Monolith（出现多限界上下文时，把功能分组为模块并加模块边界）；CA → DDD + CA（不变量变复杂、出现基本类型偏执时，引入聚合、值对象、领域事件）；Monolith → Modular Monolith（团队互相踩脚、共享数据库耦合时，拆成拥有自己 DbContext 和 schema 的模块）；Modular Monolith → Microservices（需要独立扩展或独立部署时，把模块抽成独立可部署服务）。
18. 避免反模式：不要为 CRUD 应用选 Clean Architecture（简单 CRUD 用 VSA 一个文件即可，而非 4 个项目 6+ 文件）；不要到处用 DDD（设置表不需要聚合根和值对象，用简单实体即可）；不要过早微服务（2 个开发者第一天就拆 5 个微服务是错的，先做模块化单体，有证据再抽取）；不要跳过问卷（不要因为「我总是用 Clean Architecture」就直接脚手架 4 项目 CA 方案，先问再推荐）。
19. 按场景速查：新项目需求未知 → 运行问卷；简单 CRUD API 且 1-3 开发者 → VSA；中等复杂度、长期、资深团队 → Clean Architecture；复杂领域、专门术语 → DDD + Clean Architecture；多限界上下文、多团队 → Modular Monolith；现有 N 层代码库需现代化 → Clean Architecture（迁移熟悉）；MVP/初创且速度优先 → VSA；监管/合规重 → Clean Architecture 或 DDD（强制边界）；未来需独立扩展 → Modular Monolith（可抽取）。

适用边界 · 注意事项

• 非 .NET 项目或团队不使用 dotnet-claude-kit 提供的四种架构模式时。
• 用户已经明确指定了架构且不需要重新评估时。
• 项目复杂度极低且用户只想快速搭建脚手架、不关心架构决策时。