Coupling or Uncoupling?

We all start our careers knowing that our code should be loosely coupled and have high cohesion. But can we ever achieve fully uncoupled code in a system? Not really. Coupling determines how freely we can make changes within a system, and different types of coupling may produce totally different effects.

Michael Nygard dives deep into that topic in his Uncoupling talk where he explains what coupling is, how to analyze it and what we as engineers can do to make the systems more resilient to change.

So, let's break it down. The author talks about a few types of coupling:
📍Operational. Consumer cannot run without a provider. For example, a service might fail if it can't access the database.
📍Development. Changes in the producer and consumer need to be synchronized and delivered together
📍Semantic. Changed together because of shared concepts.If a concept changes due to new business requirements, those changes need to be reflected in all downstream systems.
📍Functional. Changed together because of shared responsibility.
📍Incidental. Change together for no good reason. The E-Gate system failure serves as a prime example of incidental coupling, where an update in one system triggered a failure in another due to a shared network.

By strategically adjusting the levels of different types of coupling, we can effectively manage the impact of our changes.

#architecture #systemdesign