The Many Facets of Coupling - Enterprise Integration Patterns
Gregor's Ramblings<br>HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT
The Many Facets of Coupling<br>June 10, 2024
Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise<br>computing and architecture topics.
TOPICS<br>ALL RAMBLINGS<br>Architecture (12)<br>Cloud (14)<br>Conversations (8)<br>Design (26)<br>Events (30)<br>Gregor (4)<br>Integration (23)<br>Messaging (13)<br>Modeling (5)<br>Patterns (8)<br>Visualization (3)<br>WebServices (5)<br>Writing (12)
POPULAR RAMBLINGS
Starbucks does not use 2-phase commit
Is this architecture?
RESTful Conversations
Hub and Spoke
Correlation and Conversations
Diagram-driven Design
RECENT
Queues invert control flow but require flow control
Control Flow—The Other Half of Integration Patterns
Event-driven = Loosely coupled? Not so fast!
The Many Facets of Coupling
Serverless Loan Broker @ GCP
Serverless Loan Broker @ AWS, Part 5: Integration Patterns with CDK
Serverless Loan Broker @ AWS, Part 4: Automation
Serverless Loan Broker @AWS, Part 3: Publish-Subscribe with SNS
Loan Broker @AWS, Part 2: Recipient List
Find my posts on IT strategy, enterprise architecture, and digital transformation<br>at ArchitectElevator.com.
Coupling is integration's magic word. Loose coupling affords the participants desirable<br>properties like independent variability or operational resilience. However, as pointed<br>out in a recent blog post, coupling isn't binary nor is it a single dimension. So it's time to apply our favorite<br>architect maneuvres—seeing more dimensions and seeing shades of gray—to coupling.
Coupling is a Measure of Variability
Like most architecture concepts (and the concept of architecture itself), finding<br>a universally agreed-upon definition of coupling isn't easy. I fall back to my description<br>from many years ago:
Coupling describes the independent variability of connected systems, i.e., whether<br>a change in System A affects System B. If it does, A and B are coupled.
This definition places coupling at the center of change propagation, meaning if one component changes, does that change affect other components? Change<br>comes in many forms, for example, a change in requirements, a change in scale, or<br>a change in component latency or availability. Systems that are (more) tightly coupled<br>tend to be brittle: local changes trickle through the system. Those changes can be<br>functional, meaning the system is difficult (and risky) to change. They can also be<br>operational changes like the outage of one component. If other components are temporally<br>coupled to this component, a local issue can drag the entire system down. We call<br>such a system brittle, meaning it isn't resilient because it doesn't absorb disturbance.
Coupling Isn't Binary
I have long resented the idea of coupling being regarded as some form of bit that's<br>either set or not, meaning something is coupled or magically decoupled. As computer<br>folks, we like binary things, but unfortunately coupling (like most architecture considerations)<br>isn't one of them. My oldest and still favorite quote aptly takes the notion of coupling<br>being an on/off switch to the extreme by providing this clever advice for setting<br>the coupling bit to "false":
How do you make two systems loosely coupled? Don't connect them. (David Orchard)
So, the objective can't be to make everything loosely coupled but rather to understand<br>the nuance of coupling and the design trade-offs that are involved. For example, for<br>functional changes, if you have full control over all system components, good test<br>coverage, and high levels of automation, coupling may not be a big issue. For example,<br>method names are tightly coupled, but most modern IDEs support a rename method refactoring, which allows us to overcome the change propagation with a single (right)<br>button click.
The insight that an acceptable amount of coupling is connected to the level of control<br>leads us to my basic theorem of coupling:
The appropriate level of coupling depends on the level of control that you have over<br>the endpoints.
Coupling is Multi-Dimensional
Not only is coupling non-binary, it's also not one-dimensional. Whether a change propagates<br>through the system depends on the type of change. So, we amend our definition:
Coupling describes the independent variability of connected systems, i.e., whether<br>a change in System A affects System B. If it does, A and B are coupled with respect to this change.
For example, a location-dependent solution requires an update to each sender when<br>a recipient changes location (such as a new URL or IP address). In other words, sender<br>and receiver are coupled with respect to location, or location coupled in short. It's easy to see that even this single dimension has many nuances. For<br>example, using URLs or hostnames instead of IP addresses gives the sender and receiver<br>more variability,...