Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Balancing Coupling in Distributed Systems

Vladik Khononov
February 07, 2020
2.5k

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 “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)
  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 “"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)
  5. vladikk doit-intl.com #DDDEU AGENDA 1. WHAT IS COUPLING? 2. EXPLORE

    THE DIMENSIONS OF COUPLING 3. USE COUPLING AS A DESIGN TOOL / HEURISTIC
  6. vladikk doit-intl.com #DDDEU “Coupling defines the relationship between components” “Coupling

    defines the components’ degrees of freedom” - Michael Nygard (@mtnygard)
  7. vladikk doit-intl.com #DDDEU 1. CONTENT COUPLING 2. COMMON COUPLING 3.

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING
  8. 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”
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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:
  15. 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
  16. 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
  17. 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
  18. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. TYPE 3.

    Meaning 4. Algorithm 5. Position • Types of two variables have to match
  19. 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”
  20. 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
  21. vladikk doit-intl.com #DDDEU STATIC CONNASCENCE: 1. Name 2. Type 3.

    Meaning 4. Algorithm 5. POSITION • Order of passed values
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. vladikk doit-intl.com #DDDEU Connascence of algorithm: • Modules duplicating email

    validation logic (static) • Modules duplicating phone number validation logic (changes often) CONNASCENCE
  33. 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
  34. 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
  35. 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
  36. vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. DEVELOPMENT 4.

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

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

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

    changes When requirements change When implementation changes Always Always
  40. 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
  41. vladikk doit-intl.com #DDDEU Strength: High (Content Coupling?) Volatility: Operational /

    Semantic Distance: Minimized by Bounded Contexts UBIQUITOUS LANGUAGE
  42. 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)
  43. 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
  44. 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:
  45. 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
  46. 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
  47. 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
  48. vladikk doit-intl.com #DDDEU WRAP UP: VOLATILITY Functional: Semantic: Development: Operational:

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

    D) Maintenance Pain WRAP UP: BALANCING COUPLING