Coupling

Coupling is not intrinsically bad. Too little coupling makes systems brittle - changes have to be repeated in multiple places, system behaviour grows increasingly inconsistent, and finding 100% of the code that needs to be updated as part of a change becomes harder. Too much coupling, and systems become calcified; Updates have unintended consequences, API boundaries become incredibly verbose with large amounts of parameters and options, and figuring out how to update every piece of code impacted by a change becomes increasingly difficult.
Yet even that is too simplistic a mental model of coupling. It's not really about too much or too little, it's about appropriate coupling between layers while aligning the vector of change throughout the code with the vector of change throughout the business/application/package β whatever extrinsic forces motivate software updates. The customer journey, the customer types and categories, the organizational chart & design of a business, the third party vendors and partners, etc β the software architecture needs to align with all of it.
Alignment isn't a lack of coupling, it's the right kind of coupling in the right places. You can't build a skyscraper without cohesion between discrete pieces, whether that is steel through concrete, nuts and bolts, welding, mortar, etc. Without cohesion (coupling) you don't have a skyscraper, you have a pile of rubble. But if everything is coupled you also don't have a skyscraper, instead you have an incredibly expensive piece of abstract art that is utterly impermeable since none of the doors can be opened π


