在 .NET 后端项目里，代码组织方式会直接决定团队迭代速度。
我常见的失败模式是：Controller 太胖、EF 实体直接外露、业务规则散落在服务和仓储里。
一个可落地的分层思路
我更偏好下面这套：
- API：输入输出契约、鉴权、参数校验
- Application：用例编排、事务边界、集成事件
- Domain：实体和值对象、核心业务规则
- Infrastructure：数据库、消息队列、外部依赖
这套结构不新，但非常实用。
为什么不是“越抽象越好”
很多项目把每一层都抽成大量接口，最后连简单改动都要穿过十几个文件。
我建议把抽象用在“变化概率高”的地方，比如外部服务适配；稳定逻辑保持直接表达，减少样板代码。
CQRS 要不要上
我的判断标准很简单：
- 读写逻辑差异大、查询复杂：可以上 CQRS
- 业务还在早期探索：先保持简单 CRUD + 清晰分层
架构应该服务当前阶段，而不是展示理论完整度。
测试策略
在 .NET 项目里，单元测试和集成测试都重要，但分工不同：
- 单元测试：校验领域规则和边界条件
- 集成测试：覆盖 API、数据库、消息链路的真实行为
先把关键业务路径测稳，再扩展覆盖面，效果通常最好。