Skip to content

ALL-ARCH0003 · evidence

This page continues ALL-ARCH0003 directly from its source docstring. Read its implementation.

Each finding names the importing package, the imported package, the instability of both as a percentage, and how many packages depend on the importer, which is what says how far a change travels. The repair is a choice between inverting the arrow and moving what the two share, and both are decisions somebody has to make. The value is the number of this package’s imports that point the wrong way.

Only imports between packages this repository owns are read, since a third-party package has no instability inside this architecture. Imports within one package do not cross a component boundary and cannot violate the component principle. Declarative imports in Python __init__.py and Rust mod.rs files state a package’s public ownership surface, so they stay out of implementation arrows between the facade and its children. Test code necessarily points at production code, so those verification arrows are not production component dependencies and stay out, while dependencies among test packages are still judged. A package in an import cycle is stable and unstable at once, and the two sides each report the other, so ALL-ARCH0002 is the rule to fix first and this one settles afterward. A plugin a framework loads by name is imported by nothing static, so it reads as maximally unstable and its dependencies are judged accordingly, which is correct rather than a false positive.

  • Cites “Agile Software Development”, the Stable Dependencies Principle
  • Cites “Clean Architecture”, chapter 14, component coupling
  • Cites “Design Principles and Design Patterns”. Open reference
  • Cites “JDepend”, the tool that first computed these metrics over a package graph. Open reference