$30 off During Our Annual Pro Sale. View Details »

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

    View Slide

  2. VLAD

    KHONONOV
    @vladikk
    vladikk.com
    [email protected]

    View Slide

  3. VLAD

    KHONONOV
    @vladikk
    vladikk.com
    [email protected]

    View Slide

  4. VLAD

    KHONONOV
    @vladikk
    vladikk.com
    [email protected]

    View Slide

  5. vladikk doit-intl.com
    #KanDDDinsky
    BALANCING COUPLING


    IN SOFTWARE DESIGN

    View Slide

  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)

    View Slide

  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)

    View Slide

  8. vladikk doit-intl.com
    #KanDDDinsky
    COUPLING

    View Slide

  9. vladikk doit-intl.com
    #KanDDDinsky
    COUPLING

    View Slide

  10. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

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

    View Slide

  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)

    View Slide

  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)

    View Slide

  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

    View Slide

  15. vladikk doit-intl.com
    #KanDDDinsky
    WHAT IS

    COUPLING?

    View Slide

  16. vladikk doit-intl.com
    #KanDDDinsky
    co-

    together
    apere

    fasten
    copula

    copulare
    cople

    copler
    couple
    LATIN LATIN OLD FRENCH
    MIDDLE


    ENGLISH

    View Slide

  17. vladikk doit-intl.com
    #KanDDDinsky
    co-

    apere

    copula

    cople

    couple
    LATIN LATIN OLD FRENCH
    MIDDLE


    ENGLISH
    COUPLED = CONNECTED

    View Slide

  18. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

  19. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

  20. vladikk doit-intl.com
    #KanDDDinsky
    COUPLING

    View Slide

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


    PART OF SYSTEM DESIGN

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    - Michael Nygard (@mtnygard)

    View Slide

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

    View Slide

  28. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

  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

    View Slide

  30. vladikk doit-intl.com
    #KanDDDinsky
    DIMENSIONS

    OF COUPLING

    View Slide

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

    View Slide

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

    View Slide

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


    • Connascence
    COUPLING MODELS

    View Slide

  34. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

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


    2. COMMON COUPLING


    3. EXTERNAL COUPLING


    4. CONTROL COUPLING


    5. STAMP COUPLING


    6. DATA COUPLING

    View Slide

  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”

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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:

    View Slide

  43. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

  44. vladikk doit-intl.com
    #KanDDDinsky
    CONNASCENCE

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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;

    View Slide

  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

    View Slide

  51. vladikk doit-intl.com
    #KanDDDinsky
    STATIC CONNASCENCE:


    1. Name


    2. Type


    3. Meaning


    4. Algorithm


    5. POSITION
    • Order of passed values

    View Slide

  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

    View Slide

  53. vladikk doit-intl.com
    #KanDDDinsky
    DYNAMIC CONNASCENCE:


    1. Execution


    2. Timing


    3. Value


    4. Identity

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  57. vladikk doit-intl.com
    #KanDDDinsky
    DYNAMIC CONNASCENCE:


    1. Execution


    2. Timing


    3. VALUE


    4. Identity

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  61. vladikk doit-intl.com
    #KanDDDinsky
    • 1960s - Coupling in Structured Design


    • 1990s - Connascence


    • 2020s - Integration Strength
    COUPLING MODELS

    View Slide

  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

    View Slide

  63. vladikk doit-intl.com
    #KanDDDinsky
    INTEGRATION STRENGTH:


    1. Implementation Coupling


    2. Functional Coupling


    3. Model Coupling


    4. Contract Coupling

    View Slide

  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

    View Slide

  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!

    View Slide

  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

    View Slide

  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

    View Slide

  68. vladikk doit-intl.com
    #KanDDDinsky
    Strength
    Shared Knowledge
    INTEGRATION STRENGTH
    Implementation Coupling


    Functional Coupling


    Model Coupling


    Contract Coupling

    View Slide

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


    Functional Coupling


    Model Coupling


    Contract Coupling
    Implicit

    Interfaces
    Explicit

    Interfaces

    View Slide

  70. vladikk doit-intl.com
    #KanDDDinsky
    Strength
    Shared Knowledge
    INTEGRATION STRENGTH
    Implementation Coupling


    Functional Coupling


    Model Coupling


    Contract Coupling

    View Slide

  71. vladikk doit-intl.com
    #KanDDDinsky
    DISTANCE
    2

    View Slide

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

    View Slide

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

    View Slide

  74. vladikk doit-intl.com
    #KanDDDinsky
    COST OF CHANGE IS PROPORTIONAL


    TO THE DISTANCE BETWEEN COMPONENTS

    View Slide

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

    View Slide

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

    Coupling

    View Slide

  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

    View Slide

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

    Coupling

    View Slide

  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

    View Slide

  80. vladikk doit-intl.com
    #KanDDDinsky
    Component A Component B
    System A System B
    Functional Coupling

    View Slide

  81. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  85. vladikk doit-intl.com
    #KanDDDinsky
    SUBDOMAINS
    Supporting
    Core
    Generic

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  89. vladikk doit-intl.com
    #KanDDDinsky
    SUBDOMAINS
    Supporting
    Generic
    High Volatility
    Low Volatility
    Low Volatility
    CORE

    View Slide

  90. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

  91. vladikk doit-intl.com
    #KanDDDinsky

    View Slide

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

    View Slide

  93. vladikk doit-intl.com
    #KanDDDinsky
    BALANCING THE

    DIMENSIONS OF COUPLING

    View Slide

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


    High Strength + High Volatility = High Maintenance E
    ff
    ort


    STRENGTH & VOLATILITY

    View Slide

  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

    View Slide

  96. vladikk doit-intl.com
    #KanDDDinsky
    Distance increases coordination overhead


    High Volatility over High Distance = High Coordination E
    ff
    ort
    DISTANCE & VOLATILITY

    View Slide

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


    Pain
    STRENGTH & DISTANCE & VOLATILITY

    View Slide

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

    View Slide

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

    0 = 0 * ∞ * ∞

    View Slide

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

    0 = ∞ * ∞ * 0

    View Slide

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

    0 = ∞ * 0 * ∞

    View Slide

  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

    View Slide

  103. vladikk doit-intl.com
    #KanDDDinsky
    EXAMPLE:


    INTEGRATION STRENGTH

    View Slide

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


    Functional Coupling


    Model Coupling


    Contract Coupling
    Component A

    Component B

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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


    Functional Coupling


    Model Coupling


    CONTRACT COUPLING


    Component A

    Component B
    Dedicated integration DB

    View Slide

  109. vladikk doit-intl.com
    #KanDDDinsky
    EXAMPLE:


    DOMAIN-DRIVEN DESIGN

    View Slide

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

    0 = Functional * High * 0

    View Slide

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

    0 = Model * High * 0

    View Slide

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

    0 = ∞ * 0 * ∞

    View Slide

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

    0 = 0 * High * High

    View Slide

  114. vladikk doit-intl.com
    #KanDDDinsky
    WRAP UP

    View Slide

  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

    View Slide

  116. vladikk doit-intl.com
    #KanDDDinsky
    Strength
    Shared Knowledge
    Implementation Coupling


    Functional Coupling


    Model Coupling


    Contract Coupling
    WRAP UP: INTEGRATION STRENGTH

    View Slide

  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

    View Slide

  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)

    View Slide

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


    Pain
    WRAP UP: BALANCING COUPLING

    View Slide

  120. @vladikk vladikk.com vladik at khononov.com

    View Slide

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

    View Slide

  122. QUESTIONS?

    View Slide

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

    View Slide