journal.2018-12-20.coupling.md

GistID: 87ded2e5fe0cfac465e57235c74c362e

Presented to Medumo engineering team 2019 Q1

Presentation specs:

• macOS Terminal with font size increased by 8
• vim with this config
• Goyo.vim
• Limelight.vim
• Goyo 50x30

Coupling

I whine about this in code reviews, so let's tawk about it.

Coupling

Connected modules.

Communicating modules.

Tight coupling

Module A is "tightly coupled" with Module B when:

• It needs a lot of Module B's stuff
• It needs to know order of operations in Module B
• It's as performant as Module B is
• It needs to know where Module B lives

Tight coupling - pros/cons

• Pro: tight coupling can increase productivity
• Con: tight coupling makes change expensive

Tight coupling vs. loose coupling

A system with coupling is a system that does nothing.

We need to loosen things up.

Aspects

Most systems have a combination of coupling aspects. We'll cover 3 here:

• Platform coupling
• Temporal coupling
• Spatial coupling

Platform coupling (operability)

• Cloud provider lockin
  • "Serverless"
• Programming language
  • Monolithic apps
• Processor-specific
  • Program for ARM

Platform coupling - loosening

Reason we use standards:

• JSON
• HTTP
• AMQP

Temporal coupling (response order and time)

• Knowledge of operation order
• Often caused by shared state
• Getting result depends on dependency response time

Spatial coupling (reliability)

• Reliability depends on another's location
• Example: Service A depends on B and B is down

Blocking calls

  Android        Web App        Slack
     +              +             +
     |              |             |
    +-+            +-+            |
    |+|------------|>|            |
    |<|------------|+|            |
    |||            +-+           +-+
    |+|--------------------------|>|
    |||             |            |||
    |||             |            |||
    |<|--------------------------|+|
    +-+             |            +-+
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     |              |             |
     v              v             v

Blocking calls - coupling aspects

• PC: HTTP and JSON
• TC: Android must know to call Web App first
• TC: Android compute is sum of Web App and Slack
• SC: If Slack is down, what happens to Android?

Messaging pattern

• Think texting vs. phone
• Subscriptions over responses (e.g. Amazon order flow)
• Example: pub/sub

Draw design together

Object-oriented design

• Remember Singleton?
• Does client code need change if impl changes?
• Does impl need change if client code changes?

Look at code example

Conclusions

Favor:

• Common protocols and schemas (e.g. JSON, HTTPS, AMQP)
• Asynchronous and messaging (e.g. pub/sub) over synchronous and blocking (e.g. REST, RPC)
• Abstractions (e.g. interfaces) over concrete impls
• Isolating platform dependencies into libraries
• Immutability when possible

References

• http://www.udidahan.com/wp-content/uploads/soa_distilled_uml_china.pdf
• http://udidahan.com/2006/07/21/how-soa-helps-you-hit-the-agile-sweet-spot/
• http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling/
• https://enterprisecraftsmanship.com/2017/04/10/temporal-coupling-and-immutability/
• https://www.pluralsight.com/tech-blog/forms-of-temporal-coupling