$30 off During Our Annual Pro Sale. View Details »

Balancing Coupling in Distributed Systems

Vladik Khononov
February 07, 2020
2.2k

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.

Vladik Khononov

February 07, 2020
Tweet

Transcript

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

    View Slide

  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)

    View Slide

  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)

    View Slide

  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)

    View Slide

  5. vladikk doit-intl.com
    #DDDEU
    COUPLING

    View Slide

  6. vladikk doit-intl.com
    #DDDEU
    COUPLING

    View Slide

  7. vladikk doit-intl.com
    #DDDEU
    COUPLING

    View Slide

  8. vladikk doit-intl.com
    #DDDEU

    View Slide

  9. vladikk doit-intl.com
    #DDDEU

    View Slide

  10. vladikk doit-intl.com
    #DDDEU
















    View Slide

  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)

    View Slide

  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

    View Slide

  13. vladikk doit-intl.com
    #DDDEU
    WHAT IS
    COUPLING?

    View Slide

  14. vladikk doit-intl.com
    #DDDEU
    “Coupling defines the relationship between components”
    “Coupling defines the components’ degrees of freedom”
    - Michael Nygard (@mtnygard)

    View Slide

  15. vladikk doit-intl.com
    #DDDEU

    View Slide

  16. vladikk doit-intl.com
    #DDDEU

    View Slide

  17. vladikk doit-intl.com
    #DDDEU

    View Slide

  18. vladikk doit-intl.com
    #DDDEU

    View Slide

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

    View Slide

  20. vladikk
    COUPLING
    Design decision
    Defines the relationship between components
    Limits components’ degrees of freedom

    View Slide

  21. vladikk doit-intl.com
    #DDDEU
    DIMENSIONS
    OF COUPLING

    View Slide

  22. vladikk
    DIMENSIONS OF COUPLING
    Strength
    Distance
    Volatility

    View Slide

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

    View Slide

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

    View Slide

  25. vladikk doit-intl.com
    #DDDEU

    View Slide

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

    View Slide

  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”

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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:

    View Slide

  34. vladikk doit-intl.com
    #DDDEU

    View Slide

  35. vladikk doit-intl.com
    #DDDEU
    CONNASCENCE

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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”

    View Slide

  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

    View Slide

  42. vladikk doit-intl.com
    #DDDEU
    STATIC CONNASCENCE:
    1. Name
    2. Type
    3. Meaning
    4. Algorithm
    5. POSITION
    • Order of passed values

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  52. vladikk doit-intl.com
    #DDDEU
    DISTANCE
    2

    View Slide

  53. vladikk doit-intl.com
    #DDDEU
    • Methods
    • Classes
    • Namespaces
    • Components
    • Services
    • Systems
    DISTANCE

    View Slide

  54. vladikk doit-intl.com
    #DDDEU
    Cost of change
    Distance
    DISTANCE

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  58. vladikk doit-intl.com
    #DDDEU
    Component A Component B
    System A System B
    Connascence of Timing

    View Slide

  59. vladikk doit-intl.com
    #DDDEU
    VOLATILITY
    3

    View Slide

  60. vladikk doit-intl.com
    #DDDEU
    Connascence of algorithm:
    • Modules duplicating email validation logic (static)
    • Modules duplicating phone number validation logic (changes often)
    CONNASCENCE

    View Slide

  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

    View Slide

  62. vladikk doit-intl.com
    #DDDEU
    “Coupling defines the relationship between components”
    - Michael Nygard (@mtnygard)

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  69. vladikk doit-intl.com
    #DDDEU
    Semantic:
    Functional:
    Development:
    Operational:
    Accidental:
    When model changes
    When requirements change
    When implementation changes
    Always
    Always

    View Slide

  70. vladikk doit-intl.com
    #DDDEU
    Core:
    Supporting:
    Generic:
    High volatility
    Low volatility
    Stable
    DOMAIN-DRIVEN DESIGN: SUBDOMAINS

    View Slide

  71. vladikk doit-intl.com
    #DDDEU
    DIMENSIONS OF COUPLING
    Volatility
    Strength
    Distance

    View Slide

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

    View Slide

  73. vladikk doit-intl.com
    #DDDEU
    Pain = Strength * Volatility * Distance
    Pain = (S, V, D)

    View Slide

  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

    View Slide

  75. vladikk doit-intl.com
    #DDDEU
    BALANCING COUPLING IN
    DOMAIN-DRIVEN DESIGN

    View Slide

  76. vladikk doit-intl.com
    #DDDEU
    Strength: High (Content Coupling?)
    Volatility: Operational / Semantic
    Distance: Minimized by Bounded Contexts
    UBIQUITOUS LANGUAGE

    View Slide

  77. vladikk doit-intl.com
    #DDDEU
    Strength: Content Coupling
    Volatility: Development
    Distance: Minimal
    SHARED KERNEL

    View Slide

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

    View Slide

  79. vladikk doit-intl.com
    #DDDEU
    Distance: High
    Volatility: Semantic
    Strength: Low (Data coupling)
    OPEN-HOST SERVICE

    View Slide

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

    View Slide

  81. vladikk doit-intl.com
    #DDDEU
    Distance: High
    Volatility: High (Operational)
    Strength: Low (Data coupling)
    BETWEEN AGGREGATES

    View Slide

  82. vladikk doit-intl.com
    #DDDEU
    BALANCING COUPLING IN
    MICROSERVICES

    View Slide

  83. vladikk doit-intl.com
    #DDDEU

    View Slide

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

    View Slide

  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)

    View Slide

  86. vladikk
    WRAP UP

    View Slide

  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

    View Slide

  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:

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  93. vladikk doit-intl.com
    #DDDEU
    Distance
    Strength
    Volatility
    Pain = (S, V, D)
    Maintenance
    Pain
    WRAP UP: BALANCING COUPLING

    View Slide

  94. https://bit.ly/2ptJ5fS
    THANK
    YOU!
    @vladikk
    vladikk.com
    https://bit.ly/31nSD9c
    http://careers.doit-intl.com

    View Slide