高内聚低耦合的核心是职责清晰、边界明确、依赖可控：类须聚焦单一业务概念并用一句话定义身份，依赖必须面向接口构造注入，多变逻辑抽为策略接口，包结构按业务域物理隔离。
设计高内聚低耦合的类结构，核心是让每个类“职责清晰、边界明确、依赖可控”。它不是靠加接口或拆包堆出来的，而是从职责识别开始，一层层约束出来的。
聚焦单一业务概念，守住类的“身份”
一个类应该能用一句话说清它是谁、做什么。比如User类只表达“用户身份与状态”，字段（id、name、email、status）和方法（isActivated()、getDisplayName()）都必须服务于这个目的。
- 不放校验逻辑：setEmail()里不做邮箱格式检查，那是Validator的事；
- 不掺操作行为：不加sendWelcomeEmail()或exportToExcel()，这些变化原因不同，会稀释内聚；
- 不暴露内部细节：避免public List
getOrders()，改用不可变副本或封装视图； - 不用@Data盲目生成：可能意外暴露toString()引发循环引用，建议按需用@Getter/@Setter，关键方法手动控制。
依赖面向接口，不绑定实现细节
类之间协作要像部门对接——只认流程，不插手对方怎么干活。PaymentService不该知道用的是Alipay还是WechatPay，它只依赖PaymentProcessor接口。
- 所有外部依赖（数据库、HTTP客户端、配置）必须通过构造函数注入，类型为接口；
- 禁止在类里new具体实现，也别用Class.forName()或静态工具类（如new ObjectMapper()）；
- Service层不持有JdbcTemplate，Controller层不接触RedisTemplate，各层只依赖本层抽象；
- 测试时能直接传入new MockPaymentProcessor()，说明依赖设计合格。
把多变逻辑抽成策略接口，运行时组合
当看到if-else判断渠道、类型或规则时，基本就是行为没抽象。比如发通知、计算运费、发优惠券，都该变成独立策略。
- 定义NotificationSender接口，含send(String target, String content)和supports(String channel)；
- 实现EmailSender、SmsSender、PushSender，各自专注一种通道；
- OrderService只持NotificationSender接口，新增渠道只需加实现类+配置，原逻辑不动；
- 接口方法数控制在5个以内，超了就说明职责在膨胀，该拆。
包与模块按业务域组织，物理隔离边界
包名不是命名空间装饰，而是职责的物理映射。com.example.order下只放跟订单强相关的类，且只导出api包。
- 按业务域建包：order、product、user，而不是按技术层建controller/service/repository；
- module-info.java中只exports com.example.order.api，绝不导出impl或internal；
- 禁止循环依赖：A模块requires B，B就不能requires A，JPMS编译器会直接拦截；
- 接口由能力提供方定义并导出，实现可由其他模块提供，用provides机制解耦。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
