高内聚低耦合是可维护、可测试、可演进的底层保障，需通过单一职责、接口抽象、依赖注入、组合优于继承、按业务能力分层等实践落实。
高内聚低耦合不是风格偏好，而是可维护、可测试、可演进的底层保障。它让代码在需求变更时改得少、测得快、扩得稳。
明确类的单一职责，守住变化边界
一个类只响应一种变化原因。比如“订单状态更新”和“订单通知发送”是两个独立变化点——支付渠道换、短信接口升级、风控规则调优，各自影响不同模块。若把它们塞进同一个 OrderService，一次修改就可能牵动日志、发券、对账等无关逻辑。
- 用一句话定义类职责：“该类负责将订单从 CREATED 状态推进到 PAID，并触发对应事件”
- 发现方法里有
if (type.equals("email"))或switch (channel)，就是职责扩散信号，该拆策略了 - 校验、加解密、脱敏、格式化等通用能力，一律抽成独立工具类（如 PhoneMasker、JwtValidator），不混入业务流程
依赖必须显式、抽象、可控
类不该知道它用的是 MySQL 还是 PostgreSQL，也不该知道发短信走的是腾讯云还是自建通道。依赖越具体，替换成本越高，测试越难。
- 所有外部协作对象（数据库访问、HTTP 客户端、缓存、配置）必须通过构造函数注入，类型为接口（如 OrderRepository、NotificationSender）
- 禁用
@Autowired字段注入——它掩盖空依赖，导致脱离 Spring 就无法单元测试 - Service 层不持有
JdbcTemplate，Controller 不直接操作RedisTemplate；中间加一层抽象（CacheService、DataAccessLayer）
用组合代替继承，用接口表达行为契约
继承是强绑定，父类一动，子类跟着抖。而组合+接口能清晰表达“它能做什么”，而非“它是什么”。
立即学习“Java免费学习笔记（深入）”；
- 把多态逻辑外提：定义 PaymentStrategy 接口，由 WechatPayStrategy、AlipayStrategy 实现，而不是在 PaymentService 里写一堆
if-else - 避免
extends BaseEntity强塞字段和方法；共性行为用 interface + default method 或委托类封装 - DTO、Entity 中不放业务方法（如
User.isValid()），校验逻辑归属 UserValidator，保持数据载体纯粹
包结构按能力分层，不按技术分层
不要建 controller、service、dao 三层平铺包，那只是物理分层。应围绕业务能力组织，每个包自包含接口、实现、领域模型和测试。
- 例如：
order包下有OrderService、OrderRepository、OrderStatusTransition、OrderEvent，不跨包引用内部类 - 跨域能力（如通知、文件、搜索）抽为独立模块，通过接口被其他业务包依赖，不反向依赖
- 公共基础能力（日期、加密、异常码）放在
common模块，但禁止出现common.order这类违反分层的子包
