接口粒度需按业务场景和调用方需求动态调整：过细增加网络开销，过粗导致冗余；应以业务能力边界划分（如OrderPlacementService），而非实体或操作；方法命名须面向意图（如activateUser），避免低层语义；通过组合（如AsyncCapable）替代泛化扩展；依据调用日志与反馈持续优化，如精简返回字段或拆分高频操作。
接口粒度不能一刀切，得看业务场景和调用方实际需要。太细会引发大量远程调用、增加网络开销和协调成本；太粗又容易带出无关字段、造成数据冗余，还让客户端被迫处理不关心的逻辑。
按业务能力边界划分接口
一个接口对应一个明确的业务能力，而不是一个实体或一个操作。比如“下单”不是只做 insert order，而是包含库存校验、价格计算、优惠券核销、生成订单号等一整套闭环动作。这类能力封装成 OrderPlacementService 接口，比拆成 InventoryCheckService、PriceCalculationService 更合理——除非这些能力被多个不同流程复用，且各自演进节奏差异大。
面向调用方视角设计方法签名
接口方法名和参数要反映真实使用意图，而不是技术动作。避免出现 updateUserStatusById(Long id, Integer status) 这类低层语义方法；换成 activateUser(String userId) 或 deactivateUser(String userId)，语义清晰、职责单一、不易误用。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 客户端只关心“启用用户”，不关心状态字段叫什么、存哪张表
- 后续若状态扩展为多阶段（如 pending → active → suspended），内部实现可升级，接口无需改动
- 减少参数组合爆炸：不用靠传枚举+标志位来控制行为分支
用组合代替泛化，支持渐进式细化
当某些场景确实需要更细粒度控制时，不直接拆接口，而是通过组合方式暴露可选能力。例如主接口 PaymentClient 提供 pay(ChargeRequest)，再额外定义 AsyncCapable、Retryable 等小接口，由具体实现类按需实现。
立即学习“Java免费学习笔记（深入）”；
- 保持主契约稳定，不影响大多数调用方
- 有异步需求的系统可以显式检查 instanceof AsyncCapable，决定是否走回调路径
- 避免把所有可能的扩展点都塞进主接口，导致方法越来越多、语义越来越模糊
定期回顾接口使用日志与客户端反馈
上线后观察真实调用模式：哪些方法长期无人调用？哪些参数总传 null？哪些返回字段从不被消费？这些是粒度失衡的信号。
- 某支付接口返回 12 个字段，但 App 端只用其中 3 个 → 考虑提供精简版 payLight() 或加 @JsonIgnore 字段
- 某个 update 接口 80% 请求只改 email，其余字段恒定 → 可拆出 changeEmail(String userId, String newEmail)
- 多个服务反复调用同一组查询 → 抽取为独立聚合接口，而非让各处拼 JOIN
