Change-Coupling

You just fixed a bug in the payment module. Simple enough — an edge case in the calculation logic. You changed three files: the payment handler, a date formatting utility, and a config loader. Those three files have nothing to do with each other. You know that. You’ve always known it. You fixed the bug anyway, committed all three, and moved on. Because that’s just how this codebase works. Your import graph is lying to you When we talk about coupling, most developers think of import statements. You open a file, you look at what it imports, and you draw a mental map of dependencies. Clean Architecture tools do the same thing — they trace the explicit links between modules and draw you a diagram. ...

Ein Team plant eine größere Umstrukturierung. Drei Module sollen einem neuen Team übergeben werden, zwei weitere zusammengeführt. Der Engineering Manager ist zuversichtlich — die Architektur ist klar dokumentiert, die Übergabe sollte in zwei Sprints erledigt sein. Vier Monate später ist das Projekt noch nicht abgeschlossen. Was niemand vorher gesehen hatte: Eines der übergebenen Module hatte in den letzten 18 Monaten exklusiv einen einzigen Entwickler als Ansprechpartner — der inzwischen das Unternehmen verlassen hatte. Ein anderes Modulpaar änderte sich faktisch immer gemeinsam, obwohl im Architekturdiagramm keine Verbindung eingezeichnet war. Und ein dritter Bereich zeigte seit Monaten stetig steigende Komplexität — unbemerkt, weil niemand den Trend über Sprints hinweg verfolgt hatte. ...