Coupling

Component and Service Coupling

Lesson 29

• 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.

A depends on B INTERNALS;
!!=>> B does not change interface, but change internal logic;
A is broken because of it;

• External coupling:

  • Solution to address the coupling: enterprise service bus (e.g. Spring integration camel)

A exposes REST api;
B, C, D depend on this REST api;
!!=>> A changes endpoints to SOAP;
we do not even know how many components will be broken;

• 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)

Law of demeter

(Principle of least knowledge)

• each component should have only limited knowledge about other components; only those closely related

• each component should talk only to its friends; do not talk to strangers

• only talk to your immediate friends

Coupling tradeoffs

• 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.

Stamp coupling

Lesson 105

⚠️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.

• 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

⚠️Problem 2: bandwidth. We will transfer unnecessary data, which may cost a lot.

• ✅Solutions:

  • return partial data (e.g. via request parameters)

    • 👍solves bandwidth

    • 👋not really solves a stamp coupling (contract changes still apply)

  • use GraphQL

  • 👍👍create dedicated endpoint to receive only required information (solves both problems)