Coupling
Last updated
Was this helpful?
Last updated
Was this helpful?
Static coupling:
Afferent coupling: how many components/services depend on YOU
Efferent coupling: on how many components you depend
Temporal coupling: (described from worst to better)
Pathological coupling
One component relies on inner workings of another component.
External coupling:
Solution to address the coupling: enterprise service bus (e.g. )
control coupling:
one component passes info to another component what to do
data coupling:
when components are bounded to shared data context (e.g. have same db)
(Principle of least knowledge)
CA - incoming coupling
CE - outgoing coupling
CT - total coupling
If we redesign the system and try to make it as less coupled as possible. So we make the system fully async using messaging.
What are the tradeoffs of such loose coupling:
Workflow control. It is absolutely absent, "order placement" does not know what happens after it submits a message, will it be processed by any service at all
Error handling. What if e.g. "payment service" throws an exception.
Data consistency.
Transaction state management.
if Profile_service changes contract e.g. state to statecd Whishlist service will be affected, because it will need to update a contract.
So change in irrelevant field statewill cause a redeployment/retesting of wishlist service
return partial data (e.g. via request parameters)
use GraphQL
Problem 1 : when wishlist service needs only a name from the profile service, but you return the whole customer profile this is a STAMP COUPLING.
Problem 2: bandwidth. We will transfer unnecessary data, which may cost a lot.
Solutions:
solves bandwidth
not really solves a stamp coupling (contract changes still apply)
create dedicated endpoint to receive only required information (solves both problems)
