#216 – Forced Decoupling

In order to act on changes and effectively evolve our architectures and products, we need to take the concept of “coupling” into consideration. Coupling tells us about the degree of interdependence between software modules, such as classes or objects. When two classes are tightly coupled, they’re dependent on each other because, e.g., Class A knows “too many details” about Class B and uses that information directly in its own code. So, if a change is made to Class B, Class A would need to be changed as well to not break.

Loose coupling, or decoupling, on the other hand, means that Class A and B are weakly associated with each other, so that Class A won’t have to change if Class B does. This can be achieved through, e.g., an interface which is the “public face” of a class that other classes can interact with.

Encapsulating distinct functionality into a Platform-as-a-Service behind interfaces is a much better approach than forced decoupling through a plethora of different technology stacks, which could inhibit agility across products and teams.