When I first started programming, a lot of thought was put into minimizing coupling. We wanted everything to be as loosely coupled as possible.
Object hierarchies tend to be tightly coupled so we put effort into designing modules or packages that were loosely coupled with each other even though the objects inside were tightly coupled.
Over the last 20 years, I’ve rarely heard anyone mention coupling. During that time I’ve heard many arguments for things that lead to tightly coupled components.
What Is Coupling?
Coupling is the amount of dependency between different parts of a system.
Red lines in the images above can be any type of dependency. These most often involve
- data
- code
- interface
But it can but anything where a change in one part of the system requires a change or testing of another part
- validation rules or data constraints
- configuration
- documentation
- performance
The more tightly coupled a component is to the rest of the system, the more difficult it is to fix, enhance, or replace.
Why Does it Matter?
Consider two vendors providing the same basic functionality
You may only want basic CRUD functionality. But for a similar price, Vendor B will
- Store additional attributes in their database
- Provide a schema to use in your database (no data mapping – just use theirs)
- Sync parts of your databases
- Provide UI to manage the data
- Provide additional functionality to manage and query your data
- Provide C++/Java/Python code making it simple to access their API directly from any module rather than writing your own request-handling interface module.
Even if you won’t need most of the additional functionality, Vendor B seems like a bargain. This saves UI development and schema design. It’s great until they update their UI in a way that doesn’t work for you. Or require a schema update at a time that doesn’t fit with your development schedule. Or even worse, they increase their price or go out of business.
Many things outside of your control can have an impact on your development or ops teams with Vendor B. Vendor A can also increase their price or go out of business or have stability issues. But they are significantly easier to replace.
This is not simply a theoretical problem with vendor APIs. I’ve seen vendors increase coupling with APIs from user authentication to media license management to content moderation. It is very appealing and often smart to take advantage of the additional functionality you weren’t looking for. But it’s good to be aware of the downside and if possible create an interface module with the vendor. This way replacing the vendor only requires changes to the single interface application module.
Vendor B does not have to be a 3rd party. I’ve seen more problems with corporate common libraries and even two groups with the same project (e.g. the admin team reusing UI components from the consumer team’s frontend code and consumer teams using service modules in ways that later restrict enhancements).