Balanced Coupling
The Balanced Coupling model for software design.
Install
npx skills add vladikk/modularity --skill balanced-coupling -g -a claude-code -y- Repository
- vladikk/modularity576
- Category
- Design
- Updated
- 2mo ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
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 unbalanced, applying DDD strategic and tactical patterns, reasoning about cohesion vs coupling trade-offs, identifying distributed monolith risks, or explaining why a system is hard to change. Provides the three-dimensional framework (integration strength, distance, volatility) and the balance rule for making coupling decisions.
The Balanced Coupling Model
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.
1. Foundations: Why Coupling Matters
1.1 Coupling Is Not the Enemy
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.
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.
1.2 Complexity (via Cynefin)
The model adopts the Cynefin framework's definition of complexity:
- Clear (Simple): You make a change and know exactly what the outcome will be.
- Complicated: You don't know the outcome, but an expert does and you can consult them.
- 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.
- Chaotic: No identifiable relationship between actions and outcomes, even in hindsight.
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.
