{
  "$type": "site.standard.document",
  "canonicalUrl": "https://jacob.blog/notes/stable-dependencies-principle",
  "path": "/notes/stable-dependencies-principle",
  "publishedAt": "2025-01-04T00:00:00.000Z",
  "site": "at://did:plc:ckthoyuvsmkp254fyuinyzb2/site.standard.publication/3mndm6tiamb26",
  "tags": [
    "software-engineering",
    "architecture",
    "clean-code"
  ],
  "textContent": "> [!info] Definition\n>\n> Depend in the direction of stability.\n>\n> A component that we expect to be volatile should not be depended on by a component that is difficult to change. Otherwise, the volatile component will be difficult to change.\n\nMost of this comes from _Clean Architecture - Chapter 14: Component Coupling_.\n\nStability metrics\n\nOne way of measuring the stability of a component is to count the number of dependencies that enter and leave that component. These counts allow us to calculate the _positional stability_ of that component.\n\n- Fan-in - incoming dependencies. This metric identifies the number of classes outside this component that depend on classes within the component.\n- Fan-out - outgoing dependencies. This metric identifies the number of classes inside this component that depend on classes outside the component.\n- Instability (I) - I = Fan out / (Fan in + Fan out). This metric has the range [0, 1]. I = 0 indicates a maximally stable component. I = 1 indicates a maximally unstable component.\n\nExcerpts from Clean Architecture\n\n> It is the perversity of software that a module that you have designed to be easy to change can be made difficult to change by someone else who simply hangs a dependency on it. Not a line of source code in your module will suddenly become more challenging to change.",
  "title": "Stable Dependencies Principle"
}