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.

Transcript

1. vladikk doit-intl.com #KanDDDinsky BALANCING COUPLING IN SOFTWARE DESIGN
2. VLAD 
 KHONONOV @vladikk vladikk.com vladik@khononov.com
3. VLAD 
 KHONONOV @vladikk vladikk.com vladik@khononov.com
4. VLAD 
 KHONONOV @vladikk vladikk.com vladik@khononov.com
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!