skills.rest
materkey
materkeyCOMMUNITY
Explore all skills by this author →
GitHub

balanced-coupling

Evaluate software architecture coupling across integration strength, distance, and volatility.

1|Updated Apr 14, 2026
Search Tags:#software design#domain-driven design#modularity#architecture review#coupling analysis#service boundaries#distributed monolith
One-click install
npx skills add https://github.com/materkey/cc-plugins --skill balanced-coupling-materkey
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: balanced-coupling
Source: https://github.com/materkey/cc-plugins/tree/main/plugins/review-feature-architecture/skills/balanced-coupling
Command: npx skills add https://github.com/materkey/cc-plugins --skill balanced-coupling-materkey

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you reason about software architecture when a system feels hard to change, modules seem tangled, or service boundaries are unclear. It gives you a practical model for deciding whether parts of a system should stay close together, move apart, or interact through stronger contracts.

Core Features & Use Cases

  • Three-dimensional coupling analysis: Evaluates architecture using integration strength, distance, and volatility instead of relying on simplistic ideas like fewer dependencies always being better.
  • Boundary and modularity decisions: Helps assess whether modules, services, or bounded contexts should be merged, split, or protected with clearer contracts.
  • Distributed monolith detection: Identifies risky combinations of high coupling and high distance that make coordinated change expensive and fragile.
  • DDD-aligned review language: Connects coupling decisions to bounded contexts, aggregates, anti-corruption layers, core subdomains, supporting subdomains, and generic subdomains.
  • Use case: Review a feature architecture where frontend, backend, and shared services keep changing together, then classify the coupling pattern and recommend whether to co-locate logic, reduce shared knowledge, or introduce explicit contracts.

Quick Start

Ask the skill to evaluate the coupling between two modules or services, classify the integration strength, distance, and volatility, and explain whether the design is balanced or likely to create change friction.

Frequently Asked Questions about balanced-coupling

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

FAQPage Schema
How do I analyze software architecture coupling to decide if service boundaries support modularity?▼

Analyze software architecture coupling by classifying integration strength, socio-technical distance, and business volatility. This identifies whether component relationships support modularity or create change complexity, helping you decide if modules should merge, split, or use explicit contracts.

What is a distributed monolith and how do I detect high coupling across services?▼

A distributed monolith occurs when high coupling exists across distant services, making coordinated change expensive. Detect it by evaluating integration strength and distance to identify risky combinations where service boundaries fail to isolate changes.

How do I evaluate bounded contexts in domain-driven design for change friction?▼

Evaluate bounded contexts by assessing their coupling dimensions against business volatility. This DDD-aligned review examines shared models and functional dependencies to determine if contexts need anti-corruption layers or clearer contracts to reduce change friction.

When should I merge or split modules based on coupling analysis?▼

Merge or split modules based on balanced coupling analysis of integration strength and volatility. If components change together frequently with high integration strength, co-locate them; if distance is high but coupling remains strong, introduce explicit contracts to reduce shared knowledge.

Can I review feature-scoped architecture across frontend, backend, and shared services?▼

Yes, you can review feature-scoped architecture across frontend, backend, and shared services. The analysis classifies coupling patterns when layers change together, recommending whether to co-locate logic, reduce shared knowledge, or introduce explicit contracts.

Why does relying on fewer dependencies fail to improve software modularity?▼

Relying on fewer dependencies fails because modularity requires balanced coupling across integration strength, distance, and volatility. Simplistic dependency reduction ignores whether components actually change together, potentially increasing change complexity when business volatility is high.

Related Skills

Explore More Software Engineering Skills→
ptreezhptreezh
24

ant-network-analysis

Analyze actor network topology, centrality, stability, and dynamics from relationship data.

Community
Advanced
MovchanetsMovchanets

ddd-context-mapping

Map bounded context relationships and integration contracts for distributed DDD systems.

Community
Intermediate
SSiertsemaSSiertsema

ddd-strategic-modeling

Identify bounded contexts and subdomain classifications to produce context maps with relationships and ubiquitous language.

Community
Advanced
Ronin15Ronin15
14

hammer-dependency-analyzer

Diagnose SDL3 HammerEngine dependency health with circular dependency and layer violation reports.

Community
Advanced