balanced-coupling

Name: balanced-coupling
Author: vladikk

495stars30forks

How to install balanced-coupling?

vladikk/modularity/balanced-coupling

$npx -y skills add vladikk/modularity --skill balanced-coupling

Installs into the current project.

Summary

The Balanced Coupling model for software design. Use when: designing modular architectures, evaluating coupling between components, reviewing code modularity, deciding whether to split or merge modules/services, assessing integration patterns, classifying coupling as balanced or

Files · 1

View on GitHub

SKILL.md

1	# The Balanced Coupling Model
2
3	A comprehensive reference for understanding the Balanced Coupling model as described by Vlad Khononov. This document synthesizes the full model from the companion blog at coupling.dev, covering its foundations, dimensions, balancing mechanics, relationship to prior coupling models, and connections to domain-driven design.
4
5	---
6
7	## 1. Foundations: Why Coupling Matters
8
9	### 1.1 Coupling Is Not the Enemy
10
11	The term "coupling" has long been synonymous with bad design. The balanced coupling model challenges this assumption. According to the dictionary, coupling is simply a device for connecting parts. If a system is a set of components interacting to achieve a goal, then coupling is what connects those components and makes it possible to achieve those goals. Coupling is what makes the value of a system greater than the sum of its parts.
12
13	You cannot build a system out of fully independent components — that would go against the very definition of "system." The question is not whether to couple, but how to couple. Some forms of coupling lead to modularity; others create complexity. The balanced coupling model treats coupling not as a nuisance to eliminate but as a design tool to wield deliberately.
14
15	### 1.2 Complexity (via Cynefin)
16
17	The model adopts the Cynefin framework's definition of complexity:
18
19	- Clear (Simple): You make a change and know exactly what the outcome will be.
20	- Complicated: You don't know the outcome, but an expert does and you can consult them.
21	- Complex: The only way to determine the outcome is to make the change and observe what happens. Cause and effect can only be identified in hindsight.
22	- Chaotic: No identifiable relationship between actions and outcomes, even in hindsight.
23
24	In software design, complexity means a system where the outcomes of changes are unpredictable. The goal of modular design is to avoid situations where the effect of a change can only be identified in retrospect.
25
26	Crucially, complexity is subjective — it is a function of both system design and our cognitive limits:
27
28	```
29	complexity = f(system design, cognitive limits)
30	```
31
32	Studies suggest humans can hold only 4 +/- 1 units of information in working memory simultaneously. When the information required to make a change exceeds this cognitive capacity, the design is complex.
33
34	### 1.3 Modularity: The Opposite of Complexity
35
36	If complexity makes change outcomes unpredictable, modularity is its opposite. A modular design satisfies two criteria:
37
38	1. It is clear what parts of the system need to change.
39	2. The outcome of the change is clear and predictable.
40
41	Modularity extends a system's goals into the future. It doesn't mean preemptively implementing future requirements — that's impossible. It means making the implementation of reasonable future changes easy by minimizing the cognitive load required.
42
43	A system is a set of components interacting to achieve goals. Even a "big ball of mud" can achieve its current goals. Modular design extends the system's goals by ensuring it can continue to achieve goals as they evolve.
44
45	### 1.4 The Shared Cause
46
47	Complexity and modularity are contrasting concepts driven by the same fundamental cause: coupling. The way components are connected determines whether the system is modular or complex.
48
49	---
50
51	## 2. The Three Dimensions of Coupling
52
53	When two components are coupled, the connection between them — not the components themselves — is what determines modularity or complexity. The balanced coupling model evaluates this connection along three dimensions: integration strength, distance, and volatility.
54
55	### 2.1 Integration Strength (Knowledge)
56
57	Integration requires components to exchange knowledge about each other. The more knowledge is shared, the higher the probability that a change in one component will trigger cascading changes in others.
58
59	Rather than trying to "measure" knowledge quantitatively, the model categorizes types of knowledge. Each type involves significantly different amounts of shared knowledge. This is the Integration Strength model, which identifies four levels (from strongest/most knowledge to weakest/least):
60
61	#### Intrusive Coupling (Strongest)
62	Occurs when private interfaces or implementation details

People who liked this also viewed

6 picks

Type

balanced-coupling

495stars30forks

View on GitHub

How to install balanced-coupling?

vladikk/modularity/balanced-coupling

$npx -y skills add vladikk/modularity --skill balanced-coupling

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# The Balanced Coupling Model
2
3	A comprehensive reference for understanding the Balanced Coupling model as described by Vlad Khononov. This document synthesizes the full model from the companion blog at coupling.dev, covering its foundations, dimensions, balancing mechanics, relationship to prior coupling models, and connections to domain-driven design.
4
5	---
6
7	## 1. Foundations: Why Coupling Matters
8
9	### 1.1 Coupling Is Not the Enemy
10
11	The term "coupling" has long been synonymous with bad design. The balanced coupling model challenges this assumption. According to the dictionary, coupling is simply a device for connecting parts. If a system is a set of components interacting to achieve a goal, then coupling is what connects those components and makes it possible to achieve those goals. Coupling is what makes the value of a system greater than the sum of its parts.
12
13	You cannot build a system out of fully independent components — that would go against the very definition of "system." The question is not whether to couple, but how to couple. Some forms of coupling lead to modularity; others create complexity. The balanced coupling model treats coupling not as a nuisance to eliminate but as a design tool to wield deliberately.
14
15	### 1.2 Complexity (via Cynefin)
16
17	The model adopts the Cynefin framework's definition of complexity:
18
19	- Clear (Simple): You make a change and know exactly what the outcome will be.
20	- Complicated: You don't know the outcome, but an expert does and you can consult them.
21	- Complex: The only way to determine the outcome is to make the change and observe what happens. Cause and effect can only be identified in hindsight.
22	- Chaotic: No identifiable relationship between actions and outcomes, even in hindsight.
23
24	In software design, complexity means a system where the outcomes of changes are unpredictable. The goal of modular design is to avoid situations where the effect of a change can only be identified in retrospect.
25
26	Crucially, complexity is subjective — it is a function of both system design and our cognitive limits:
27
28	```
29	complexity = f(system design, cognitive limits)
30	```
31
32	Studies suggest humans can hold only 4 +/- 1 units of information in working memory simultaneously. When the information required to make a change exceeds this cognitive capacity, the design is complex.
33
34	### 1.3 Modularity: The Opposite of Complexity
35
36	If complexity makes change outcomes unpredictable, modularity is its opposite. A modular design satisfies two criteria:
37
38	1. It is clear what parts of the system need to change.
39	2. The outcome of the change is clear and predictable.
40
41	Modularity extends a system's goals into the future. It doesn't mean preemptively implementing future requirements — that's impossible. It means making the implementation of reasonable future changes easy by minimizing the cognitive load required.
42
43	A system is a set of components interacting to achieve goals. Even a "big ball of mud" can achieve its current goals. Modular design extends the system's goals by ensuring it can continue to achieve goals as they evolve.
44
45	### 1.4 The Shared Cause
46
47	Complexity and modularity are contrasting concepts driven by the same fundamental cause: coupling. The way components are connected determines whether the system is modular or complex.
48
49	---
50
51	## 2. The Three Dimensions of Coupling
52
53	When two components are coupled, the connection between them — not the components themselves — is what determines modularity or complexity. The balanced coupling model evaluates this connection along three dimensions: integration strength, distance, and volatility.
54
55	### 2.1 Integration Strength (Knowledge)
56
57	Integration requires components to exchange knowledge about each other. The more knowledge is shared, the higher the probability that a change in one component will trigger cascading changes in others.
58
59	Rather than trying to "measure" knowledge quantitatively, the model categorizes types of knowledge. Each type involves significantly different amounts of shared knowledge. This is the Integration Strength model, which identifies four levels (from strongest/most knowledge to weakest/least):
60
61	#### Intrusive Coupling (Strongest)
62	Occurs when private interfaces or implementation details

People who liked this also viewed

6 picks

Type