企业级 Spring Boot 后端开发

问题背景

企业 Spring Boot 后端往往不是“能不能跑”的问题，而是边界越来越难守：controllers 直接查库，services 引用 API DTO，entities 被当作响应对象，跨模块依赖绕开 facade，事务和事件散落各处。结果就是改一个接口要翻多个包，OpenAPI 与实现不同步，数据库约束和代码状态互相矛盾，测试只能靠人工兜底。

工作方式

该技能把变更约束成可审查的工程流程。先读 AGENTS.md、README、docs/**、API guidelines、build files，再看最近 git history，并明确受影响模块、contracts、migrations、tests 和不动边界。若涉及 public API、persistence shape、依赖方向、auth、transaction 或 error semantics，先作为设计决策说明权衡。

核心能力包括：

• 模块边界：优先 modular monolith，其他模块只通过 facade 访问，避免 controller/service/repository 跨模块直连。
• API-first：先更新 OpenAPI，再生成 contracts，controller 实现生成接口，请求映射为 command records，结果映射为 response records。
• 分层契约：controller 管 HTTP 与 DTO，service 管业务、事务和事件，repository 只管持久化查询，mapper 保持无副作用。
• 持久化与事务：用数据库约束保护 invariant，谨慎修改 Flyway，事务放在 service 层并避免自调用绕过 AOP。
• 安全审计：身份从 token/session 推导，敏感操作写 audit log，避免记录 secrets、tokens、完整个人标识。

适用边界

它更适合已有明确仓库规范、OpenAPI、Modulith/architecture tests 的企业级 Java 后端。若项目是脚本型服务、快速原型、或强依赖现有非标准 DTO 风格，应优先遵守仓库约定，而不是机械套用该技能。对于 public API、migration、auth、transaction 的变更，仍需保持小步可编译，并让测试、OpenAPI 与数据库约束一起通过。