SDP

Stable Dependencies Principle

“Depend in the direction of stability.” – Robert C. Martin

A module should only depend on modules that are more stable than itself.

When to use

When deciding dependency direction.

Why it matters

  • Resilience: If an unstable module (one that changes often) depends on a stable module, it’s fine. If a stable module depends on an unstable one, the stable module becomes unstable (it breaks whenever the unstable one changes).

Signs of Violation

  • Your core business logic depends on the UI layer.
  • Your database schema definition depends on a random utility script.

Explanation

Problem

“Stability” here doesn’t mean “doesn’t crash”. It means “hard to change”. A module is stable if lots of other modules depend on it (responsibile). A module is unstable if it depends on lots of others but nobody depends on it (irresponsible).

You don’t want your rock-solid core functionalities to depend on a volatile GUI widget.

Solution

Ensure dependencies point towards modules that change less often.

Real world analogy

Building a house. The foundation (stable) should not depend on the wallpaper (volatile). You can change wallpaper easily. You can’t change the foundation easily.

Pros and Cons

Pros Cons
  • Architectural integrity
    		•
  • Requires discipline
    		•

    Comparison

    • SAP: Works with SDP. Stable components should be abstract.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)