balanced-coupling

Solid

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.

Code & Development 201 stars 6 forks Updated 1 months ago NOASSERTION

Install

View on GitHub

Quality Score: 80/100

Stars 20%
77
Recency 20%
75
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

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

Details

Author
vladikk
Repository
vladikk/modularity
Created
1 months ago
Last Updated
1 months ago
Language
HTML
License
NOASSERTION

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Solid

design

Designs modular high-level architectures from functional requirements and produces design documents for each module. Use when designing a new system, creating architecture documentation, or producing module-level design specs with integration contracts and test specifications.

423 Updated 1 months ago
vladikk
API & Backend Solid

convex-backend

Convex backend development guidelines. Use when writing Convex functions, schemas, queries, mutations, actions, or any backend code in a Convex project. Triggers on tasks involving Convex database operations, real-time subscriptions, file storage, or serverless functions.

1,320 Updated 3 months ago
CloudAI-X
Web & Frontend Featured

nw-fp-algebra-driven-design

Algebra-driven API design with monoids, semigroups, and interpreters via algebraic equations

508 Updated 5 days ago
nWave-ai
AI & Automation Solid

craft-content-modeling

Craft CMS 5 content modeling — sections, entry types, fields, Matrix, relations, project config, and content architecture strategy. Covers everything editors and developers need to structure content in Craft. Triggers on: section types (single, channel, structure), entry types, field types, field layout, Matrix configuration, nested entries, relatedTo, eager loading, .with(), .eagerly(), categories, tags, globals, global sets, preloadSingles, propagation, multi-site content, URI format, project config, YAML, content architecture, content strategy, taxonomy, asset volumes, filesystems, image transforms, user groups, permissions, entries-as-taxonomy, entrify. Always use when planning content architecture, creating sections/fields, configuring Matrix, setting up relations, or making content modeling decisions.

45 Updated 4 days ago
michtio