coupling-analysislisted

# Coupling analysis How hard a system is to change safely is mostly a function of its coupling: how much one part must know about another, and how far a change ripples. Good architecture is not about eliminating coupling (impossible) but directing it: toward stable things, in one direction, across as few boundaries as possible. ## Method 1. **Measure the two directions.** Afferent coupling (how many things depend on this module: its responsibility) and efferent coupling (how many things this module depends on: its fragility). A module with high afferent coupling must be stable (many depend on it); a module with high efferent coupling is hard to change (it breaks when any dependency does). Tools compute these; the numbers name your risky modules. 2. **Point dependencies toward stability.** Stable, abstract things (interfaces, core domain: see domain-driven-design) are depended upon; volatile, concrete things (UI, external integrations) depend outward and are depended on by nothing (the dependency-inversion instinct: see layered-architecture, hexagonal-architecture). A stable module depending on a volatile one is inverted and will churn. 3. **Enforce one-way dependencies.** Cycles are the enemy: two modules depending on each other cannot be understood, tested, or deployed independently (see circular-dependencies). Pick a direction per boundary, enforce it with tooling (architecture-fitness tests, package/visibility rul