> For the complete documentation index, see [llms.txt](https://amartyushov.gitbook.io/tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://amartyushov.gitbook.io/tech/app-aspects/software-architecture/coupling.md).

# Coupling

## Component and Service Coupling

[Lesson 29](https://developertoarchitect.com/lessons/lesson29.html)

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

* :thumbsdown:**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](https://camel.apache.org/components/3.16.x/spring-integration-component.html))

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

{% hint style="info" %}

* 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
  {% endhint %}

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2F53iFiqyUdLAxn541qJNx%2FScreenshot%202022-04-26%20at%2008.36.34.png?alt=media\&token=e6f44143-9bb2-4847-a250-a6ad02d4b62a)

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2FntoThrinskxOYUWny25p%2FScreenshot%202022-04-26%20at%2008.38.13.png?alt=media\&token=fb7d8bec-07c1-48e8-81ac-b09e8edc27f7)

### [Coupling tradeoffs](https://developertoarchitect.com/lessons/lesson59.html)

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2FA5MS1JnXDfv4TU1mrcmu%2FScreenshot%202022-04-26%20at%2008.50.28.png?alt=media\&token=1843a22b-c8b7-4232-8473-04ac06d2f749)

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

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2FHz4t7jvA5qiK5LsWtO3p%2FScreenshot%202022-04-26%20at%2008.52.16.png?alt=media\&token=f1abc5aa-ec0b-48be-8811-3c70e2825e5f)

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](https://developertoarchitect.com/lessons/lesson105.html)

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2FKTOIM8r0Wu98ot4VOcwL%2FScreenshot%202022-05-02%20at%2009.34.56.png?alt=media\&token=f9a92cb2-0ee4-48f2-ae39-8de5f46f2fd4)

:warning:**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 `state`will cause a redeployment/retesting of wishlist service

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

![](https://415484505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxtoAXZwwOc4XGto8vb%2Fuploads%2FseCUqCtpxhphbKtcq01Q%2FScreenshot%202022-05-02%20at%2009.40.02.png?alt=media\&token=ed77f3a7-2ebf-4c0d-8520-2a0dc95f37a3)

* :white\_check\_mark:Solutions:
  * return partial data (e.g. via request parameters)
    * :thumbsup:solves bandwidth
    * :wave:not really solves a stamp coupling (contract changes still apply)
  * use GraphQL
  * :thumbsup::thumbsup:create dedicated endpoint to receive only required information (solves both problems)