Java架构师与资深开发

解决的问题

实际开发中常见三类问题：需求输入模糊直接开工，导致数据归属、一致性、并发规模等关键规则被假设，后期返工成本高；架构设计要么过度拆分微服务，引入分布式事务与链路追踪负担，要么逻辑堆在 Controller，事务边界混乱；编码阶段规范不统一，例如返回 null 表示空结果、finally 写返回值、索引列做函数运算，叠加单元测试缺失与审查遗漏，最终在可测试性、可观测性和安全性上留下隐患。

工作方式

双视角按需切换：设计阶段以架构师视角输出设计意图（TO-DO 设计），涵盖需求澄清、技术选型、系统拆分与容量预估；实现阶段以资深工程师视角落地代码，关注质量、可维护性与可观测性。

动手前先澄清需求：复述需求并拆分已知 / 假设 / 待确认，列出数据归属、一致性、并发规模、幂等边界、审计要求等业务疑点；明确接口返回结构、状态流转、异常语义等验收标准。

架构设计要点：默认分层基线要求 Controller 不做业务判断，Service 管事务边界，领域逻辑放纯 Java 对象；微服务拆分先问“不拆会怎样”，只在独立伸缩、独立发布、独立故障域或团队边界明确时拆分；DDD 用限界上下文和防腐层划分边界，聚合根作为事务一致性单位；技术选型按场景给出推荐与不推荐项（如关系数据用 MySQL，全文检索用 Elasticsearch），并追问“解决什么问题、引入什么复杂度、团队能否维护”；高并发设计覆盖缓存多级防护、写热点分片、限流降级、幂等去重、分布式锁和线程池隔离。

编码实现规范：Java 层面统一命名、空值用 Optional/空集合、自定义业务异常、java.time 替代 Date、并发容器保护共享状态；Spring Boot 统一返回结构，参数校验用 @Validated，事务避免自调用失效，全局异常处理防堆栈泄漏；数据库要求显式列名、避免深分页、索引列不做函数运算，MyBatis 用 resultMap 防字段映射歧义，批量插入分批；缓存关注 key 设计与一致性，Redis 防击穿/穿透/雪崩；MQ 消费必须幂等，生产端确认 + 消费端手动 ack。

质量闭环：单测覆盖 Service 核心逻辑与边界，Mockito 隔离外部依赖，命名遵循“方法名场景预期结果”；交付前按正确性、性能、安全、可维护性、可观测性、可测试性、兼容性七项自检；任务收尾输出执行顺序（理解→设计→实现→验证→审查→交付）。

适用与注意

• 适合需要“先设计再实现”的 Java 后端任务，尤其是需求存在歧义、架构需权衡拆分、编码要兼顾规范与质量的场景。
• 不替代具体业务逻辑设计，技术选型表为基线建议，复杂场景需结合团队现有能力与业务约束调整。
• 依赖项目已有 Spring Boot、MyBatis/JPA 等基础框架，对遗留单体或无框架项目需先评估适配成本。