balanced-coupling
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
npx skills add vladikk/modularity --skill balanced-coupling --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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
- 1. Foundations: Why Coupling Matters
- 1.1 Coupling Is Not the Enemy
- 1.2 Complexity (via Cynefin)
- 1.3 Modularity: The Opposite of Complexity
- 1.4 The Shared Cause
- 2. The Three Dimensions of Coupling
- 2.1 Integration Strength (Knowledge)
- 2.2 Distance
- 2.3 Volatility
- 3. Fractal Geometry
- 4. Balancing the Dimensions
- 4.1The Four Extreme Combinations (Strength x Distance)
- 4.2The Balance Rule
- 4.3Pragmatic Balance (Adding Volatility)
What does the balanced-coupling skill do?
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
How do I install it?
Run `npx skills add vladikk/modularity --skill balanced-coupling --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From vladikk/modularity, a repository with 502 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.