核心是用接口定义契约，调用方只依赖“做什么”，不关心“谁来做”和“怎么做”；接口仅声明方法签名、使用专有业务dto、禁止框架注解、保持单一职责；依赖通过构造器或setter显式注入，支持多态替换与编译期隔离。
核心在于：用接口定义契约，让调用方只依赖“做什么”，不关心“谁来做”和“怎么做”。模块之间不再通过具体类名硬编码关联，而是靠编译期可验证的接口类型通信。
接口作为唯一通信契约
每个业务能力都抽象为一个接口，比如 PaymentService、NotificationSender、InventoryChecker。这些接口只声明方法签名，不含实现、不带框架注解、不暴露三方字段。模块间交互仅围绕这些轻量契约展开，不牵扯数据库实体、API响应体或配置细节。
- 接口方法参数和返回值必须是专有业务 DTO（如 ChargeRequest、SendResult），字段按业务语义命名（payeeAccount 而非 alipayUserId）
- 禁止在接口方法上加 @RequestBody、@Valid 等框架级注解——它们会把 Web 层细节泄漏到业务契约中
- 接口不继承、不组合其他接口，保持单一职责；一个接口只表达一种能力，避免“大而全”的聚合接口
运行时对象创建完全可控
调用方不主动 new 实现类，也不通过 ApplicationContext.getBean() 或 ServiceLoader.load() 动态查找。所有依赖都通过构造器或 setter 显式注入，使依赖关系在代码中一目了然。
- 单元测试时，可直接 new MockPaymentService() 传入，无需启动 Spring 容器
- 不同环境（开发/测试/灰度/生产）只需替换注入的实现类：本地用 SimulatedPaymentService，线上用 AlipayPaymentService
- 杜绝静态工厂、全局单例、ServiceLocator 模式——它们把依赖藏在运行时，破坏编译期隔离
多态调用屏蔽实现差异
业务逻辑代码只面向接口编程。比如订单服务中调用 paymentService.charge(request)，它不知道背后是支付宝、微信还是模拟支付。方法执行时由 JVM 根据实际注入的对象类型动态绑定，这种运行时多态让替换实现零成本。
- 新增支付渠道？只需新增一个实现类，实现同一接口，再调整注入配置即可，订单主流程代码一行不改
- 异常统一为业务语义异常（如 InsufficientBalanceException），而非 AlipayApiNetworkException，上层无需感知底层技术栈
- DTO 字段随业务演进独立调整，不与数据库表或三方 API 响应强绑定，避免“牵一发而动全身”的连锁修改
模块边界清晰，变更影响可控
当模块只依赖接口，而不依赖具体类，它的编译期依赖就从“某个实现类”降为“一组方法契约”。这意味着：
- 实现类内部重构（如换数据库、改算法、拆分逻辑）只要不改接口，就不会触发上游模块重新编译
- 两个模块即使部署在不同服务进程中，只要接口一致，就能通过 RPC 或消息完成协作
- 团队并行开发时，前端可基于接口定义先写调用逻辑，后端同步开发实现，互不阻塞
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
