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.

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