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

Balancing Coupling in Software Design (KanDDDinsky 2022)

Balancing Coupling in Software Design (KanDDDinsky 2022)

We are used to treating coupling as the necessary evil. Hence, we aim to break systems apart into the smallest services possible, in the ever-lasting quest of decoupling everything. But what results are we getting by following this reasoning? — Instead of the promised land of evolvable systems, many such “decouple everything” endeavors lead straight into the chains of distributed monoliths. Can we do better? What if there is a better way to handle coupling in distributed systems? Or even, what if instead of fighting coupling, we can use it as a heuristic for designing systems that are actually evolvable and maintainable? That’s exactly what you will learn in this session: what coupling is, and how you can use it as a design tool. We will start by taking a journey through time, and explore the different models of evaluating coupling. Next, we will combine the existing knowledge into a coherent model — a simple function for evaluating a system’s decomposition into components. This function will allow you to assess the expected effort for evolving a system and use it as a heuristic for optimizing architectural design decisions.

Vladik Khononov

November 19, 2022
Tweet

More Decks by Vladik Khononov

Other Decks in Programming

Transcript

  1. vladikk doit-intl.com #KanDDDinsky BALANCING COUPLING IN SOFTWARE DESIGN

  2. VLAD 
 KHONONOV @vladikk vladikk.com [email protected]

  3. VLAD 
 KHONONOV @vladikk vladikk.com [email protected]

  4. VLAD 
 KHONONOV @vladikk vladikk.com [email protected]

  5. vladikk doit-intl.com #KanDDDinsky BALANCING COUPLING IN SOFTWARE DESIGN

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

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

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

  9. vladikk doit-intl.com #KanDDDinsky COUPLING

  10. vladikk doit-intl.com #KanDDDinsky

  11. vladikk doit-intl.com #KanDDDinsky 💩 💩 💩 💩 💩 💩 💩

    💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩 💩
  12. vladikk doit-intl.com #KanDDDinsky “"As small as possible”… is almost universally

    bad advice in so ft ware design. Some critical logic is going to cross those boundaries and result in poorly implemented, preventable workarounds” 
 - Mathias Verraes (@mathiasverraes)
  13. vladikk doit-intl.com #KanDDDinsky “There are many useful and revealing heuristics

    for defining the boundaries of a service. Size is one of the least useful.” 
 - Nick Tune (@ntcoding)
  14. vladikk doit-intl.com #KanDDDinsky AGENDA 1. WHAT IS COUPLING? 2. EXPLORE

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

  16. vladikk doit-intl.com #KanDDDinsky co- 
 together apere 
 fasten copula

    
 copulare cople 
 copler couple LATIN LATIN OLD FRENCH MIDDLE ENGLISH
  17. vladikk doit-intl.com #KanDDDinsky co- 
 apere 
 copula 
 cople

    
 couple LATIN LATIN OLD FRENCH MIDDLE ENGLISH COUPLED = CONNECTED
  18. vladikk doit-intl.com #KanDDDinsky

  19. vladikk doit-intl.com #KanDDDinsky

  20. vladikk doit-intl.com #KanDDDinsky COUPLING

  21. vladikk doit-intl.com #KanDDDinsky COUPLING IS AN INHERENT PART OF SYSTEM

    DESIGN
  22. vladikk doit-intl.com #KanDDDinsky Downstream Component Upstream Component depends on

  23. vladikk doit-intl.com #KanDDDinsky Downstream Component Upstream Component depends on Change

  24. vladikk doit-intl.com #KanDDDinsky Downstream Component Upstream Component depends on Change

  25. vladikk doit-intl.com #KanDDDinsky Downstream Component Upstream Component depends on Change

  26. vladikk doit-intl.com #KanDDDinsky “Coupling defines the components’ degrees of freedom”

    
 - Michael Nygard (@mtnygard)
  27. vladikk doit-intl.com #KanDDDinsky Downstream Component Upstream Component depends on

  28. vladikk doit-intl.com #KanDDDinsky

  29. vladikk doit-intl.com #KanDDDinsky COUPLING Should only allow changes that we

    actually need Design decision Defines the relationship between components Limits components’ degrees of freedom
  30. vladikk doit-intl.com #KanDDDinsky DIMENSIONS 
 OF COUPLING

  31. vladikk doit-intl.com #KanDDDinsky DIMENSIONS OF COUPLING Distance Volatility Strength

  32. vladikk doit-intl.com #KanDDDinsky STRENGTH 1

  33. vladikk doit-intl.com #KanDDDinsky • Coupling in Structured Design • Connascence

    COUPLING MODELS
  34. vladikk doit-intl.com #KanDDDinsky

  35. vladikk doit-intl.com #KanDDDinsky 1. CONTENT COUPLING 2. COMMON COUPLING 3.

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

    EXTERNAL COUPLING 4. CONTROL COUPLING 5. STAMP COUPLING 6. DATA COUPLING • Directly referencing another module’s “contents” - implementation details • Private interfaces • “GO TO”
  37. vladikk doit-intl.com #KanDDDinsky 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
  38. vladikk doit-intl.com #KanDDDinsky 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
  39. vladikk doit-intl.com #KanDDDinsky 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
  40. vladikk doit-intl.com #KanDDDinsky 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
  41. vladikk doit-intl.com #KanDDDinsky 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
  42. vladikk doit-intl.com #KanDDDinsky 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:
  43. vladikk doit-intl.com #KanDDDinsky

  44. vladikk doit-intl.com #KanDDDinsky CONNASCENCE

  45. vladikk doit-intl.com #KanDDDinsky 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
  46. vladikk doit-intl.com #KanDDDinsky STATIC CONNASCENCE: 1. Name 2. Type 3.

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

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

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

    MEANING 4. Algorithm 5. Position • Conventions used to assign meaning to values • “Magic numbers” • int status = 7;
  50. vladikk doit-intl.com #KanDDDinsky 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
  51. vladikk doit-intl.com #KanDDDinsky STATIC CONNASCENCE: 1. Name 2. Type 3.

    Meaning 4. Algorithm 5. POSITION • Order of passed values
  52. vladikk doit-intl.com #KanDDDinsky 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
  53. vladikk doit-intl.com #KanDDDinsky DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3.

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

    Value 4. Identity • Execution must be carried out in a given order • No intervening execution • Dynamic equivalent of connascence of position
  55. vladikk doit-intl.com #KanDDDinsky 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
  56. vladikk doit-intl.com #KanDDDinsky 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
  57. vladikk doit-intl.com #KanDDDinsky DYNAMIC CONNASCENCE: 1. Execution 2. Timing 3.

    VALUE 4. Identity
  58. vladikk doit-intl.com #KanDDDinsky 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
  59. vladikk doit-intl.com #KanDDDinsky DYNAMIC CONNASCENCE: Execution Timing Value Identity Execution

    in a given order Execution after a set amount of time Values have to change together Reference the same instance of an object
  60. vladikk doit-intl.com #KanDDDinsky 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
  61. vladikk doit-intl.com #KanDDDinsky • 1960s - Coupling in Structured Design

    • 1990s - Connascence • 2020s - Integration Strength COUPLING MODELS
  62. vladikk doit-intl.com #KanDDDinsky • Remix of structured design and connascence

    models • Focuses on the knowledge shared between the connected components • Practical applicability INTEGRATION STRENGTH
  63. vladikk doit-intl.com #KanDDDinsky INTEGRATION STRENGTH: 1. Implementation Coupling 2. Functional

    Coupling 3. Model Coupling 4. Contract Coupling
  64. vladikk doit-intl.com #KanDDDinsky INTEGRATION STRENGTH 1. IMPLEMENTATION COUPLING 2. Functional

    Coupling 3. Model Coupling 4. Contract Coupling • Dependence on implementation details • Integration through private interfaces • Fragile • Implicit
  65. vladikk doit-intl.com #KanDDDinsky INTEGRATION STRENGTH 1. Implementation Coupling 2. FUNCTIONAL

    COUPLING 3. Model Coupling 4. Contract Coupling • Functionally related • Implementing closely-related business functionality • Change in business requirements affect both components • Don’t have to be physically integrated!
  66. vladikk doit-intl.com #KanDDDinsky INTEGRATION STRENGTH 1. Implementation Coupling 2. Functional

    Coupling 3. MODEL COUPLING 4. Contract Coupling • Sharing a model of the business domain • Structures • Hinders evolution of the shared model
  67. vladikk doit-intl.com #KanDDDinsky INTEGRATION STRENGTH 1. Implementation Coupling 2. Functional

    Coupling 3. Model coupling 4. CONTRACT COUPLING • Explicit integration contract • Integration-specific model • Decoupled from the implementation model
  68. vladikk doit-intl.com #KanDDDinsky Strength Shared Knowledge INTEGRATION STRENGTH Implementation Coupling

    Functional Coupling Model Coupling Contract Coupling
  69. vladikk doit-intl.com #KanDDDinsky Strength Shared Knowledge INTEGRATION STRENGTH Implementation Coupling

    Functional Coupling Model Coupling Contract Coupling Implicit 
 Interfaces Explicit 
 Interfaces
  70. vladikk doit-intl.com #KanDDDinsky Strength Shared Knowledge INTEGRATION STRENGTH Implementation Coupling

    Functional Coupling Model Coupling Contract Coupling
  71. vladikk doit-intl.com #KanDDDinsky DISTANCE 2

  72. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services System s
  73. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services System s Coordination
  74. vladikk doit-intl.com #KanDDDinsky COST OF CHANGE IS PROPORTIONAL TO THE

    DISTANCE BETWEEN COMPONENTS
  75. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services System s Coordination
  76. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services System s Coordination Lifecycle 
 Coupling
  77. vladikk doit-intl.com #KanDDDinsky • Defines the components’ lifecycle coupling •

    Sets the probability of “collateral” cascading changes • A ff ected by the type of encapsulation boundaries • Can also be a ff ected by the organizational structure DISTANCE
  78. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services Coordination Lifecycle 
 Coupling
  79. vladikk doit-intl.com #KanDDDinsky DISTANCE Statem ents M ethods Classes Nam

    espaces Com ponents (M icro)Services (M icro)Services Coordination Lifecycle 
 Coupling One 
 Team Multiple 
 Teams
  80. vladikk doit-intl.com #KanDDDinsky Component A Component B System A System

    B Functional Coupling
  81. vladikk doit-intl.com #KanDDDinsky

  82. vladikk doit-intl.com #KanDDDinsky VOLATILITY 3

  83. vladikk doit-intl.com #KanDDDinsky How o ft en do the coupled

    components change? VOLATILITY
  84. vladikk doit-intl.com #KanDDDinsky • Subdomain is an area of activity

    required for the company to achieve its goals • Business building blocks • Coherent set of interrelated use cases SUBDOMAINS
  85. vladikk doit-intl.com #KanDDDinsky SUBDOMAINS Supporting Core Generic

  86. vladikk doit-intl.com #KanDDDinsky SUBDOMAINS Supporting CORE Generic • The company’s

    competitive advantage • What it does differently from its competitors • New invention or optimizing existing processes • How it makes money (or hopes to)
  87. vladikk doit-intl.com #KanDDDinsky SUBDOMAINS Supporting Core GENERIC • “Solved problems”

    • Things all companies are doing in the same way • Cheaper to buy / adopt than to build in-house
  88. vladikk doit-intl.com #KanDDDinsky SUBDOMAINS SUPPORTING Core Generic • Implemented in-house

    • Provide no competitive advantage • Needed by Core Subdomains • No innovation, optimization, or intellectual property
  89. vladikk doit-intl.com #KanDDDinsky SUBDOMAINS Supporting Generic High Volatility Low Volatility

    Low Volatility CORE
  90. vladikk doit-intl.com #KanDDDinsky

  91. vladikk doit-intl.com #KanDDDinsky

  92. vladikk doit-intl.com #KanDDDinsky DIMENSIONS OF COUPLING Volatility Strength Distance

  93. vladikk doit-intl.com #KanDDDinsky BALANCING THE 
 DIMENSIONS OF COUPLING

  94. vladikk doit-intl.com #KanDDDinsky Strength increases cascading changes High Strength +

    High Volatility = High Maintenance E ff ort STRENGTH & VOLATILITY
  95. vladikk doit-intl.com #KanDDDinsky Strength increases cascading changes Distance increases coordination

    overhead High Strength over High Distance = High Cost of Evolving the System STRENGTH & DISTANCE
  96. vladikk doit-intl.com #KanDDDinsky Distance increases coordination overhead High Volatility over

    High Distance = High Coordination E ff ort DISTANCE & VOLATILITY
  97. vladikk doit-intl.com #KanDDDinsky Distance Strength Volatility Pain = 𝑓 (S,

    V, D) Maintenance Pain STRENGTH & DISTANCE & VOLATILITY
  98. vladikk doit-intl.com #KanDDDinsky Pain = 𝑓 (S, V, D) STRENGTH

    & DISTANCE & VOLATILITY Pain = Strength * Volatility * Distance
  99. vladikk doit-intl.com #KanDDDinsky PAIN = 𝑓 (S, V, D) Pain

    = Strength * Volatility * Distance 
 0 = 0 * ∞ * ∞
  100. vladikk doit-intl.com #KanDDDinsky PAIN = 𝑓 (S, V, D) Pain

    = Strength * Volatility * Distance 
 0 = ∞ * ∞ * 0
  101. vladikk doit-intl.com #KanDDDinsky PAIN = 𝑓 (S, V, D) Pain

    = Strength * Volatility * Distance 
 0 = ∞ * 0 * ∞
  102. vladikk doit-intl.com #KanDDDinsky 1. Eliminate accidental coupling 2. Reduce integration

    strength as much as possible 3. If strength and volatility is high: reduce distance PAIN = S * V * D
  103. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH

  104. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH Implementation Coupling Functional Coupling

    Model Coupling Contract Coupling Component A 
 Component B
  105. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH IMPLEMENTATION COUPLING Functional Coupling

    Model Coupling Contract Coupling Component A 
 Component B Not intended 
 for integration
  106. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH Implementation Coupling FUNCTIONAL COUPLING

    Model Coupling Contract Coupling Component A 
 Component B Have to operate on the same data
  107. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH Implementation Coupling Model Coupling

    MODEL COUPLING Contract Coupling Component A 
 Component B BI imports data for analysis
  108. vladikk doit-intl.com #KanDDDinsky EXAMPLE: INTEGRATION STRENGTH Implementation Coupling Functional Coupling

    Model Coupling CONTRACT COUPLING Component A 
 Component B Dedicated integration DB
  109. vladikk doit-intl.com #KanDDDinsky EXAMPLE: DOMAIN-DRIVEN DESIGN

  110. vladikk doit-intl.com #KanDDDinsky AGGERGATES Pain = Strength * Volatility *

    Distance 
 0 = Functional * High * 0
  111. vladikk doit-intl.com #KanDDDinsky BOUNDED CONTEXTS Pain = Strength * Volatility

    * Distance 
 0 = Model * High * 0
  112. vladikk doit-intl.com #KanDDDinsky SUPPORTING SUBDOMAINS Pain = Strength * Volatility

    * Distance 
 0 = ∞ * 0 * ∞
  113. vladikk doit-intl.com #KanDDDinsky ANTICORRUPTION LAYER, OPEN-HOST SERVICE, PUBLISHED LANGUAGE Pain

    = Strength * Volatility * Distance 
 0 = 0 * High * High
  114. vladikk doit-intl.com #KanDDDinsky WRAP UP

  115. vladikk doit-intl.com #KanDDDinsky • 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
  116. vladikk doit-intl.com #KanDDDinsky Strength Shared Knowledge Implementation Coupling Functional Coupling

    Model Coupling Contract Coupling WRAP UP: INTEGRATION STRENGTH
  117. vladikk doit-intl.com #KanDDDinsky • The coordination e ff ort and

    cost of a change is proportional to the distance between the a ff ected components • Couples components’ lifecycles WRAP UP: DISTANCE
  118. vladikk doit-intl.com #KanDDDinsky WRAP UP: VOLATILITY • How often do

    the coupled components have to change? • Affects the actual effort • Can be estimated using domain-driven design’s subdomains: Core (high), Supporting (low), Generic (low)
  119. vladikk doit-intl.com #KanDDDinsky Distance Strength Volatility Pain = 𝑓 (S,

    V, D) Maintenance Pain WRAP UP: BALANCING COUPLING
  120. @vladikk vladikk.com vladik at khononov.com

  121. @vladikk vladikk.com vladik at khononov.com

  122. QUESTIONS?

  123. @vladikk vladikk.com vladik at khononov.com THANK YOU!