Balancing Coupling in Distributed Systems

B90ab53ba7cf16ed1a4bb679cc6751d7?s=47 Vladik Khononov
February 07, 2020
990

Balancing Coupling in Distributed Systems

We are taught to avoid coupling like a plague. Over the years we’ve introduces numerous design and architectural patterns that decouple systems. But what exactly is coupling? What types of coupling are out there? Are all of them equally bad? Or maybe there is a “good” coupling?

In this talk, I’ll share my thoughts on the subject of coupling in distributed systems, and will answer all of the above questions.

B90ab53ba7cf16ed1a4bb679cc6751d7?s=128

Vladik Khononov

February 07, 2020
Tweet

Transcript

  1. vladikk doit-intl.com #DDDEU BALANCING COUPLING IN DISTRIBUTED SYSTEMS

  2. vladikk doit-intl.com #DDDEU “System design is inherently about boundaries (what’s

    in, what’s out, what spans, what moves between), and about tradeoffs. It reshapes what is outside, just as it shapes what is inside.” - Ruth Malan (@ruthmalan)
  3. vladikk doit-intl.com #DDDEU “System design is inherently about boundaries (what’s

    in, what’s out, what spans, what moves between), and about tradeoffs. It reshapes what is outside, just as it shapes what is inside.” - Ruth Malan (@ruthmalan)
  4. vladikk doit-intl.com #DDDEU “System design is inherently about boundaries (what’s

    in, what’s out, what spans, what moves between), and about tradeoffs. It reshapes what is outside, just as it shapes what is inside.” - Ruth Malan (@ruthmalan)
  5. vladikk doit-intl.com #DDDEU COUPLING

  6. vladikk doit-intl.com #DDDEU COUPLING

  7. vladikk doit-intl.com #DDDEU COUPLING

  8. vladikk doit-intl.com #DDDEU

  9. vladikk doit-intl.com #DDDEU

  10. vladikk doit-intl.com #DDDEU

  11. vladikk doit-intl.com #DDDEU “"As small as possible”… is almost universally

    bad advice in software design. Some critical logic is going to cross those boundaries and result in poorly implemented, preventable workarounds” - Mathias Verraes (@mathiasverraes)
  12. vladikk doit-intl.com #DDDEU AGENDA 1. WHAT IS COUPLING? 2. EXPLORE

    THE DIMENSIONS OF COUPLING 3. USE COUPLING AS A DESIGN TOOL / HEURISTIC
  13. vladikk doit-intl.com #DDDEU WHAT IS COUPLING?

  14. vladikk doit-intl.com #DDDEU “Coupling defines the relationship between components” “Coupling

    defines the components’ degrees of freedom” - Michael Nygard (@mtnygard)
  15. vladikk doit-intl.com #DDDEU

  16. vladikk doit-intl.com #DDDEU

  17. vladikk doit-intl.com #DDDEU

  18. vladikk doit-intl.com #DDDEU

  19. vladikk doit-intl.com #DDDEU COUPLING IS AN INHERENT PART OF SYSTEM

    DESIGN
  20. vladikk COUPLING Design decision Defines the relationship between components Limits

    components’ degrees of freedom
  21. vladikk doit-intl.com #DDDEU DIMENSIONS OF COUPLING

  22. vladikk DIMENSIONS OF COUPLING Strength Distance Volatility

  23. vladikk doit-intl.com #DDDEU STRENGTH 1

  24. vladikk doit-intl.com #DDDEU COMPOSITE / STRUCTURED DESIGN

  25. vladikk doit-intl.com #DDDEU

  26. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING
  27. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Directly referencing another module’s implementation details • Private interfaces • “GO TO”
  28. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Communicate through globally accessible memory space • Unstructured global data item • Global byte array
  29. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Communicate through globally accessible primitive value or an array of primitive values • Global variable
  30. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • A module controls execution logic of another module • Close familiarity with its behavior and execution context • The controlled module doesn’t have enough information (input) to control its own behavior
  31. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Modules communicate through exchanging data structures • Data structures are the modules’ implementation details • Sensitive to changes in the data structures
  32. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Modules communicate through exchanging primitive types • Communicating by sharing minimum information • Integration specific data
  33. vladikk doit-intl.com #DDDEU Referencing implementation details Globally accessible memory Global

    variable Controlling behavior Exchanging data records Minimizing integration interface CONTENT COUPLING: COMMON COUPLING: EXTERNAL COUPLING: CONTROL COUPLING: STAMP COUPLING: DATA COUPLING:
  34. vladikk doit-intl.com #DDDEU

  35. vladikk doit-intl.com #DDDEU CONNASCENCE

  36. vladikk doit-intl.com #DDDEU CONNASCENCE “Having been born together” (Latin) Components

    are connnascent (born together) if: • A change in one component, requires a change in another component • You can postulate a change that would require both components to change
  37. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. Type 3.

    Meaning 4. Algorithm 5. Position DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3. Value 4. Identity
  38. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. NAME 2. Type 3.

    Meaning 4. Algorithm 5. Position • Two variables reference the same thing • Need to have the same name
  39. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. TYPE 3.

    Meaning 4. Algorithm 5. Position • Types of two variables have to match
  40. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. Type 3.

    MEANING 4. Algorithm 5. Position • Conventions used to assign meaning to values • “Magic numbers”
  41. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. Type 3.

    Meaning 4. ALGORITHM 5. Position • Same algorithm is applied in multiple modules • Assume expected behaviour • E.g. encoding, encryption
  42. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. Type 3.

    Meaning 4. Algorithm 5. POSITION • Order of passed values
  43. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: Name Type Meaning Algorithm Position

    Two variables need to have the same name Types have to match Conventions for assinging meaning to values A common algorithm is used or assumed Values must be passed in a specific order
  44. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3.

    Value 4. Identity
  45. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: 1. EXECUTION 2. Timing 3.

    Value 4. Identity • Execution must be carried out in a given order • With no intervening execution • Dynamic equivalent of connascence of position
  46. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: 1. Execution 2. TIMING 3.

    Value 4. Identity • Execution in a set amount of time • E.g.: Timeouting a request • E.g.: Turning off an X-Ray machine
  47. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3.

    VALUE 4. Identity • Values have to change together • Logical transaction • E.g.: Arithmetic constraint • E.g.: Replicated data • E.g.: Business invariant
  48. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3.

    Value 4. IDENTITY • Two objects must reference the same instance of another object • E.g.: Unit of work
  49. vladikk doit-intl.com #DDDEU DYNAMIC CONNASCENCE: Execution Timing Value Identity Execution

    in a giving order Execution after a set amount of time Values have to change together Reference the same instance of an object
  50. vladikk doit-intl.com #DDDEU Connascence of Identity Connascence of Value Connascence

    of Timing Connascence of Execution Connascence of Position Connascence of Algorithm Connascence of Meaning Connascence of Type Connascence of Name Content Coupling Common Coupling External Coupling Control Coupling Stamp Coupling Data Coupling Strength Refactor
  51. vladikk doit-intl.com #DDDEU Connascence of Identity Connascence of Value Connascence

    of Timing Connascence of Execution Connascence of Position Connascence of Algorithm Connascence of Meaning Connascence of Type Connascence of Name Content Coupling Common Coupling External Coupling Control Coupling Stamp Coupling Data Coupling Strength Refactor
  52. vladikk doit-intl.com #DDDEU DISTANCE 2

  53. vladikk doit-intl.com #DDDEU • Methods • Classes • Namespaces •

    Components • Services • Systems DISTANCE
  54. vladikk doit-intl.com #DDDEU Cost of change Distance DISTANCE

  55. vladikk doit-intl.com #DDDEU COST OF CHANGE IS INVERSELY PROPORTIONAL TO

    THE DISTANCE BETWEEN COMPONENTS
  56. vladikk doit-intl.com #DDDEU Refactor to lower levels of connascence /

    coupling Minimize connascence that crosses encapsulation boundaries Maximize the connascence within encapsulation boundaries USING CONNASCENCE
  57. vladikk doit-intl.com #DDDEU Connascence of Identity Connascence of Value Connascence

    of Timing Connascence of Execution Connascence of Position Connascence of Algorithm Connascence of Meaning Connascence of Type Connascence of Name Content Coupling Common Coupling External Coupling Control Coupling Stamp Coupling Data Coupling Strength Refactor
  58. vladikk doit-intl.com #DDDEU Component A Component B System A System

    B Connascence of Timing
  59. vladikk doit-intl.com #DDDEU VOLATILITY 3

  60. vladikk doit-intl.com #DDDEU Connascence of algorithm: • Modules duplicating email

    validation logic (static) • Modules duplicating phone number validation logic (changes often) CONNASCENCE
  61. vladikk doit-intl.com #DDDEU How often do the components change? What

    are the reasons for those changes? Do they have shared reasons of change? VOLATILITY
  62. vladikk doit-intl.com #DDDEU “Coupling defines the relationship between components” -

    Michael Nygard (@mtnygard)
  63. vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. Development 4.

    Operational 5. Accidental
  64. vladikk doit-intl.com #DDDEU 1. SEMANTIC 2. Functional 3. Development 4.

    Operational 5. Accidental • Components share common business concepts • Share model of the business domain • Have to change when the model changes
  65. vladikk doit-intl.com #DDDEU 1. Semantic 2. FUNCTIONAL 3. Development 4.

    Operational 5. Accidental • Components are functionally coupled • Shared responsibility • Co-evolve when requirements change
  66. vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. DEVELOPMENT 4.

    Operational 5. Accidental • Dependency on implementation details
  67. vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. Development 4.

    OPERATIONAL 5. Accidental • A component cannot function without another one
  68. vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. Development 4.

    Operational 5. ACCIDENTAL • Components have to co-evolve for no particular reason
  69. vladikk doit-intl.com #DDDEU Semantic: Functional: Development: Operational: Accidental: When model

    changes When requirements change When implementation changes Always Always
  70. vladikk doit-intl.com #DDDEU Core: Supporting: Generic: High volatility Low volatility

    Stable DOMAIN-DRIVEN DESIGN: SUBDOMAINS
  71. vladikk doit-intl.com #DDDEU DIMENSIONS OF COUPLING Volatility Strength Distance

  72. vladikk doit-intl.com #DDDEU Distance Strength Volatility Pain = (S, V,

    D) Maintenance Pain
  73. vladikk doit-intl.com #DDDEU Pain = Strength * Volatility * Distance

    Pain = (S, V, D)
  74. vladikk doit-intl.com #DDDEU Eliminate accidental coupling Reduce connascence as much

    as possible Mitigate volatility by integration specific interfaces Reduce distance PAIN = S * V * D
  75. vladikk doit-intl.com #DDDEU BALANCING COUPLING IN DOMAIN-DRIVEN DESIGN

  76. vladikk doit-intl.com #DDDEU Strength: High (Content Coupling?) Volatility: Operational /

    Semantic Distance: Minimized by Bounded Contexts UBIQUITOUS LANGUAGE
  77. vladikk doit-intl.com #DDDEU Strength: Content Coupling Volatility: Development Distance: Minimal

    SHARED KERNEL
  78. vladikk doit-intl.com #DDDEU Strength: Stamp coupling Volatility: Semantic Distance: Low

    PARTNERSHIP
  79. vladikk doit-intl.com #DDDEU Distance: High Volatility: Semantic Strength: Low (Data

    coupling) OPEN-HOST SERVICE
  80. vladikk doit-intl.com #DDDEU Volatility: High (Operational) Strength: High (Connascence of

    Value & Identity) Distance: Low AGGREGATE
  81. vladikk doit-intl.com #DDDEU Distance: High Volatility: High (Operational) Strength: Low

    (Data coupling) BETWEEN AGGREGATES
  82. vladikk doit-intl.com #DDDEU BALANCING COUPLING IN MICROSERVICES

  83. vladikk doit-intl.com #DDDEU

  84. vladikk doit-intl.com #DDDEU Distance: Grows Balance: Volatility vs. Strength DECOMPOSING

    MONOLITHS
  85. vladikk doit-intl.com #DDDEU “System design is inherently about boundaries (what’s

    in, what’s out, what spans, what moves between), and about tradeoffs. It reshapes what is outside, just as it shapes what is inside.” - Ruth Malan (@ruthmalan)
  86. vladikk WRAP UP

  87. vladikk doit-intl.com #DDDEU • Defines the relationship between a system’s

    components • Is an inherent part of system design • Happens in 3 dimensions: strength, volatility, distance WRAP UP: COUPLING
  88. vladikk doit-intl.com #DDDEU WRAP UP: STRENGTH Referencing implementation details Globally

    accessible memory Global variable Controlling behavior Exchanging data records Minimizing integration interface CONTENT COUPLING: COMMON COUPLING: EXTERNAL COUPLING: CONTROL COUPLING: STAMP COUPLING: DATA COUPLING:
  89. vladikk doit-intl.com #DDDEU WRAP UP: STRENGTH STATIC CONNASCENCE: Name: Type:

    Meaning: Algorithm: Position: Two variables need to have the same name Types have to match Conventions for assinging meaning to values A common algorithm is used or assumed Values must be passed in a specific order
  90. vladikk doit-intl.com #DDDEU WRAP UP: STRENGTH DYNAMIC CONNASCENCE: Execution Timing

    Value Identity Execution in a giving order Execution after a set amount of time Values have to change together Reference the same instance of an object
  91. vladikk doit-intl.com #DDDEU • Location: Methods, Classes, Namespaces, Components, Services,

    Systems • The cost of a change of related components is inversely proportional to the distance between them WRAP UP: DISTANCE
  92. vladikk doit-intl.com #DDDEU WRAP UP: VOLATILITY Functional: Semantic: Development: Operational:

    Accidental: When requirements change When model changes When implementation changes Always Always
  93. vladikk doit-intl.com #DDDEU Distance Strength Volatility Pain = (S, V,

    D) Maintenance Pain WRAP UP: BALANCING COUPLING
  94. https://bit.ly/2ptJ5fS THANK YOU! @vladikk vladikk.com https://bit.ly/31nSD9c http://careers.doit-intl.com