第四章：依赖方向与稳定抽象原则

在模块边界设计中，依赖关系不仅仅是代码层面的引用，更是架构信任链路的载体。**稳定依赖原则（SDP）**、**稳定抽象原则（SAP）** 与 **依赖倒置原则（DIP）** 共同构成了管理模块间依赖方向的黄金三角。

4.1 依赖方向判定：不稳定度（I）的计算

SDP 的核心思想是：不稳定的模块（易变）应该依赖稳定的模块（不变），反之则要警惕。我们通过计算模块的 不稳定度（I） 来量化这种风险。

• 传入依赖（Ca）： 有多少外部模块依赖你（扇入）？
• 传出依赖（Ce）： 你依赖了多少外部模块（扇出）？

公式：I = Ce / (Ca + Ce) —— I 的取值范围是 [0, 1]。

4.2 稳定性与抽象度的平衡（SAP）

SAP 指出：一个模块如果非常稳定（I=0），则它必须是抽象的（A≈1），以便能够被扩展；如果一个模块非常不稳定（I=1），则它可以是具体的（A≈0）。

主序列距离（D）：D = |A + I - 1|。最理想的组件落在“主序列”上（D=0）。D 值过大（如超过0.5）的组件通常预示着设计问题。

标准做法：对这个 ConfigLoader 提取 ConfigProvider 接口（提高 A 值），并利用依赖注入（DIP）让具体实现离开主链路。

4.3 依赖倒置在边界上的落地

DIP 是实施 SDP 和 SAP 的战术手段。它要求高层次模块不应依赖低层次模块，两者都应依赖抽象。

• 信任链路： 方向从具体的生产者指向抽象的消费者（接口）。在大型业务系统中，我们通常会在多个微服务之间建立这种信任，让调用方依赖服务端的接口包，而非实现包。
• 数据流与控制流： 数据流顺着依赖方向流动（调用者传入数据），控制流则逆着依赖方向流动（调用者控制流程）。
• 选型权衡： 引入接口层会增加系统复杂度和间接性。对于团队内部、几乎没有变化的模块，过度抽象反而降低开发效率。通常建议：跨团队边界、易变逻辑、外部集成点必须使用 DIP。

4.4 落地步骤与验收标准

在具体项目中落实依赖方向与稳定抽象原则，建议按以下步骤执行，并在架构看板中持续监控。

1. 依赖扫描与矩阵化： 使用 Architecture Eval 或定制脚本，生成全量模块的依赖矩阵。标记所有违反单向依赖的循环。
2. 计算度量： 对每个模块计算 Ca、Ce、I、A、D 五元组。生成散点图，标出位于“痛苦区”（D>0.5）的模块。
3. 识别变与不变： 访谈各模块所有者，标记出易变业务逻辑和稳定基础设施。
4. 制定重构清单：
   • 对落在痛苦区的稳定具体模块：提取接口。
   • 对跨越边界的直接 new：改为工厂或 DI 注入。
   • 对循环依赖：引入中间层或事件总线。
5. 设置门禁： 在 CI 中引入依赖规则引擎，禁止新模块的 D 值超过团队容忍阈值（如 < 0.6）。

验收标准