Balancing Coupling in Distributed Systems

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

View Slide

#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)

View Slide

#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.”

View Slide

#DDDEU
COUPLING

View Slide

#DDDEU

View Slide

#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)

View Slide

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

View Slide

#DDDEU
WHAT IS
COUPLING?

View Slide

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

View Slide

#DDDEU

View Slide

#DDDEU
COUPLING IS AN INHERENT
PART OF SYSTEM DESIGN

View Slide

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

View Slide

#DDDEU
DIMENSIONS
OF COUPLING

View Slide

vladikk
DIMENSIONS OF COUPLING
Strength
Distance
Volatility

View Slide

#DDDEU
STRENGTH
1

View Slide

#DDDEU
COMPOSITE /
STRUCTURED DESIGN

View Slide

#DDDEU

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON COUPLING
3. EXTERNAL COUPLING
4. CONTROL COUPLING
5. STAMP COUPLING
6. DATA COUPLING

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON COUPLING
4. CONTROL COUPLING
5. STAMP COUPLING
6. DATA COUPLING
• Directly referencing another module’s
implementation details
• Private interfaces
• “GO TO”

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON COUPLING
4. CONTROL COUPLING
5. STAMP COUPLING
6. DATA COUPLING
• Communicate through globally accessible
memory space
• Unstructured global data item
• Global byte array

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON COUPLING
4. CONTROL COUPLING
5. STAMP COUPLING
6. DATA COUPLING
• Communicate through globally accessible
primitive value or an array of primitive
values
• Global variable

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON 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

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON 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

View Slide

#DDDEU
1. CONTENT COUPLING
2. COMMON COUPLING
4. CONTROL COUPLING
5. STAMP COUPLING
6. DATA COUPLING
• Modules communicate through
exchanging primitive types
• Communicating by sharing minimum
information
• Integration specific data

View Slide

#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:

View Slide

#DDDEU

View Slide

#DDDEU
CONNASCENCE

View Slide

#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

View Slide

#DDDEU
STATIC CONNASCENCE:
1. Name
2. Type
3. Meaning
4. Algorithm
5. Position
DYNAMIC CONNASCENCE:
1. Execution
2. Timing
3. Value
4. Identity

View Slide

#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

View Slide

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

View Slide

#DDDEU
STATIC CONNASCENCE:
1. Name
2. Type
3. MEANING
4. Algorithm
5. Position
• Conventions used to assign meaning to
values
• “Magic numbers”

View Slide

#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

View Slide

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

View Slide

#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

View Slide

#DDDEU
1. Execution
2. Timing
3. Value
4. Identity

View Slide

#DDDEU
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

View Slide

#DDDEU
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

View Slide

#DDDEU
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

View Slide

#DDDEU
1. Execution
2. Timing
3. Value
4. IDENTITY
• Two objects must reference the same
instance of another object
• E.g.: Unit of work

View Slide

#DDDEU
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

View Slide

#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

View Slide

#DDDEU
DISTANCE
2

View Slide

#DDDEU
• Methods
• Classes
• Namespaces
• Components
• Services
• Systems
DISTANCE

View Slide

#DDDEU
Cost of change
Distance
DISTANCE

View Slide

#DDDEU
COST OF CHANGE IS INVERSELY PROPORTIONAL
TO THE DISTANCE BETWEEN COMPONENTS

View Slide

#DDDEU
Refactor to lower levels of connascence / coupling
Minimize connascence that crosses encapsulation boundaries
Maximize the connascence within encapsulation boundaries
USING CONNASCENCE

View Slide

#DDDEU
Connascence of Identity
Connascence of Value
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

View Slide

#DDDEU
Component A Component B
System A System B

View Slide

#DDDEU
VOLATILITY
3

View Slide

#DDDEU
Connascence of algorithm:
• Modules duplicating email validation logic (static)
• Modules duplicating phone number validation logic (changes often)
CONNASCENCE

View Slide

#DDDEU
How often do the components change?
What are the reasons for those changes?
Do they have shared reasons of change?
VOLATILITY

View Slide

#DDDEU
“Coupling defines the relationship between components”
- Michael Nygard (@mtnygard)

View Slide

#DDDEU
1. Semantic
2. Functional
3. Development
4. Operational
5. Accidental

View Slide

#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

View Slide

#DDDEU
1. Semantic
2. FUNCTIONAL
3. Development
4. Operational
5. Accidental
• Components are functionally coupled
• Shared responsibility
• Co-evolve when requirements change

View Slide

#DDDEU
1. Semantic
2. Functional
3. DEVELOPMENT
4. Operational
5. Accidental
• Dependency on implementation details

View Slide

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

View Slide

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

View Slide

#DDDEU
Semantic:
Functional:
Development:
Operational:
Accidental:
When model changes
When requirements change
When implementation changes
Always
Always

View Slide

#DDDEU
Core:
Supporting:
Generic:
High volatility
Low volatility
Stable
DOMAIN-DRIVEN DESIGN: SUBDOMAINS

View Slide

#DDDEU
DIMENSIONS OF COUPLING
Volatility
Strength
Distance

View Slide

#DDDEU
Distance
Strength
Volatility
Pain = (S, V, D)
Maintenance
Pain

View Slide

#DDDEU
Pain = Strength * Volatility * Distance
Pain = (S, V, D)

View Slide

#DDDEU
Eliminate accidental coupling
Reduce connascence as much as possible
Mitigate volatility by integration specific interfaces
Reduce distance
PAIN = S * V * D

View Slide

#DDDEU
BALANCING COUPLING IN
DOMAIN-DRIVEN DESIGN

View Slide

#DDDEU
Strength: High (Content Coupling?)
Volatility: Operational / Semantic
Distance: Minimized by Bounded Contexts
UBIQUITOUS LANGUAGE

View Slide

#DDDEU
Strength: Content Coupling
Volatility: Development
Distance: Minimal
SHARED KERNEL

View Slide

#DDDEU
Strength: Stamp coupling
Volatility: Semantic
Distance: Low
PARTNERSHIP

View Slide

#DDDEU
Distance: High
Volatility: Semantic
Strength: Low (Data coupling)
OPEN-HOST SERVICE

View Slide

#DDDEU
Volatility: High (Operational)
Strength: High (Connascence of Value & Identity)
Distance: Low
AGGREGATE

View Slide

#DDDEU
Distance: High
Volatility: High (Operational)
Strength: Low (Data coupling)
BETWEEN AGGREGATES

View Slide

#DDDEU
BALANCING COUPLING IN
MICROSERVICES

View Slide

#DDDEU

View Slide

#DDDEU
Distance: Grows
Balance: Volatility vs. Strength
DECOMPOSING MONOLITHS

View Slide

#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.”

View Slide

vladikk
WRAP UP

View Slide

#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

View Slide

#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:

View Slide

#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

View Slide

#DDDEU
WRAP UP: STRENGTH
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

View Slide

#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

View Slide

#DDDEU
WRAP UP: VOLATILITY
Functional:
Semantic:
Development:
Operational:
Accidental:
When requirements change
When model changes
When implementation changes
Always
Always

View Slide

#DDDEU
Distance
Strength
Volatility
Pain = (S, V, D)
Maintenance
Pain
WRAP UP: BALANCING COUPLING

View Slide

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

View Slide

Balancing Coupling in Distributed Systems

Balancing Coupling in Distributed Systems

Vladik Khononov

More Decks by Vladik Khononov

Featured

Transcript