Balancing Coupling in Distributed Systems

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

vladikk doit-intl.com #DDDEU COUPLING

Slide 6

Slide 6 text

vladikk doit-intl.com #DDDEU COUPLING

Slide 7

Slide 7 text

vladikk doit-intl.com #DDDEU COUPLING

Slide 8

Slide 8 text

vladikk doit-intl.com #DDDEU

Slide 9

Slide 9 text

vladikk doit-intl.com #DDDEU

Slide 10

Slide 10 text

vladikk doit-intl.com #DDDEU

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

vladikk doit-intl.com #DDDEU AGENDA 1. WHAT IS COUPLING? 2. EXPLORE THE DIMENSIONS OF COUPLING 3. USE COUPLING AS A DESIGN TOOL / HEURISTIC

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

vladikk doit-intl.com #DDDEU

Slide 16

Slide 16 text

vladikk doit-intl.com #DDDEU

Slide 17

Slide 17 text

vladikk doit-intl.com #DDDEU

Slide 18

Slide 18 text

vladikk doit-intl.com #DDDEU

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

vladikk doit-intl.com #DDDEU DIMENSIONS OF COUPLING

Slide 22

Slide 22 text

vladikk DIMENSIONS OF COUPLING Strength Distance Volatility

Slide 23

Slide 23 text

vladikk doit-intl.com #DDDEU STRENGTH 1

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

vladikk doit-intl.com #DDDEU

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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”

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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:

Slide 34

Slide 34 text

vladikk doit-intl.com #DDDEU

Slide 35

Slide 35 text

vladikk doit-intl.com #DDDEU CONNASCENCE

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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”

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

vladikk doit-intl.com #DDDEU DISTANCE 2

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

vladikk doit-intl.com #DDDEU VOLATILITY 3

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

vladikk doit-intl.com #DDDEU 1. Semantic 2. Functional 3. Development 4. Operational 5. ACCIDENTAL • Components have to co-evolve for no particular reason

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

vladikk doit-intl.com #DDDEU

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

Slide 86

Slide 86 text

vladikk WRAP UP

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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:

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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