第 1 章：依赖方向与系统耦合度

1.1 依赖方向的定义

依赖方向决定架构弹性。正向依赖（数据流与依赖流一致）导致紧耦合。反向依赖（数据流与依赖流相反）实现松耦合和可测试性。

1.2 模块边界与职责

清晰的模块边界依赖稳定的抽象接口。接口属于高层（调用方），而非低层（实现方）。

1.3 耦合度量化指标

• 扇出 (Fan-out)： 一个模块直接依赖的其他模块数量。扇出高则耦合度高。
• 扇入 (Fan-in)： 依赖该模块的其他模块数量。扇入高表示模块被复用，不一定代表高耦合。
• 不稳定性 (Instability)： I = 扇出 / (扇入 + 扇出)。值越接近 1，模块越不稳定，越容易被变更影响。
• 抽象程度 (Abstractness)： A = 抽象元素数 / 总元素数。稳定的模块应具有高抽象程度。

1.4 选型权衡与风险点

1.5 落地步骤与验收标准

1. 识别模块间的数据流和信任链路。
2. 提取高层模块需要的抽象接口。
3. 反转依赖方向：高层依赖接口，低层实现接口。
4. 使用依赖注入框架（如 Spring, Guice）或工厂模式组装依赖。
5. 设置架构测试（ArchUnit）验证依赖规则。

// 高层模块定义的契约（属主为调用方）
public interface PaymentProcessor {
    Result process(Order order);
}

// 低层模块实现契约（依赖倒置）
public class StripeProcessor implements PaymentProcessor {
    public Result process(Order order) {
        // 具体实现细节
    }
}