Spring Boot 架构模式

要解决的工程问题

Spring Boot 开发中容易陷入架构混乱：控制器直接注入 Repository 导致业务逻辑散落在 Web 层，JPA 实体因默认 EAGER 加载引发性能雪崩，只读接口未标记 @Transactional(readOnly = true) 造成不必要的写锁，通用异常捕获掩盖真实错误信息，配置硬编码难以适配多环境部署。这些问题在项目扩张时会被放大，增加维护成本与故障风险。

核心实践与检查点

技能围绕分层架构梳理关键规范：

• Controller 仅处理 HTTP 关注点，业务逻辑必须委托给 Service 层
• Repository 仅负责持久化，禁止直接在控制器中注入，避免绕过服务层
• 实体关系默认 FetchType.LAZY，仅在明确需要时才使用 EAGER 或实体图优化
• 请求/响应强制使用 DTO，禁止直接暴露 JPA 实体，减少数据泄露与耦合
• 服务层按读写范围标记 @Transactional，只读方法需添加 readOnly = true 提升性能

异常处理需遵循 RFC 7807 标准，通过全局处理器返回 ProblemDetail，替代笼统的 Exception 捕获。针对 N+1 查询问题，推荐使用实体图或 JOIN FETCH 优化。测试层面建议结合 @SpringBootTest 与测试容器（Testcontainers）进行集成验证。

适用边界

该检查清单适用于标准 Spring Boot 分层架构项目，微服务拆分或领域驱动设计（DDD）场景可能需要调整层间职责。对于复杂的领域模型，需结合具体业务权衡 DTO 与实体的转换策略，避免过度抽象导致冗余代码。