balanced-coupling

Evaluates software coupling using integration strength, distance, and volatility dimensions.

9|Updated Jul 17, 2026
One-click install
npx skills add https://github.com/Yassimba/loom --skill balanced-coupling-yassimba
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: balanced-coupling
Source: https://github.com/Yassimba/loom/tree/main/skills/balanced-coupling
Command: npx skills add https://github.com/Yassimba/loom --skill balanced-coupling-yassimba

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It helps you decide whether components, modules, or services are coupled in a way that makes your system hard to change, and guides split-or-merge decisions with a structured model instead of gut feeling. ## Core Features & Use Cases - Three-Dimensional Coupling Analysis: Classify coupling by integration strength (intrusive, functional, model, contract), distance (code, organizational, runtime), and volatility (via DDD subdomains). - Balance Rule for Design Decisions: Apply the rule that modularity emerges when strength and distance counterbalance each other, and that low volatility can neutralize unbalanced coupling. - Use Case: When reviewing whether to split a service into microservices, use the model to check if high integration strength across a high-distance boundary signals a distributed monolith risk before committing to the split. ## Quick Start Use the balanced-coupling skill to evaluate whether the checkout and billing modules in this codebase are balanced or drifting toward a distributed monolith.

Frequently Asked Questions about balanced-coupling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether to split a module or microservice?

Evaluate integration strength and distance between the components. High strength across high distance indicates tight coupling and distributed monolith risk, while low strength across high distance indicates balanced loose coupling that supports a split.

What is the balanced coupling model in software design?

It is Vlad Khononov's framework that evaluates coupling along three dimensions: integration strength, distance, and volatility. Modularity emerges when strength and distance counterbalance each other, expressed as MODULARITY = STRENGTH XOR DISTANCE.

How does domain-driven design relate to coupling decisions?

DDD subdomains estimate volatility: core subdomains change often and need careful coupling management, while supporting and generic subdomains tolerate pragmatic shortcuts. Bounded contexts and integration patterns map to distance and integration strength levels.

When is tight coupling acceptable in a codebase?

Tight coupling is acceptable when volatility is low, meaning the component rarely changes. The full balance rule is BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY, so stable legacy code with poor coupling causes little practical harm.

Does this model apply without microservices?

Yes, the model is fractal and applies at every abstraction level, from methods and classes to modules within a single deployable unit. At each level, the highest distance is that level's boundary, so cross-module coupling in a monolith can still be unbalanced.