code-modularization-evaluator

# Code Modularization Evaluator

Evaluate code modularization using the Balanced Coupling Model from Vlad Khononov's "Balancing Coupling in Software Design." This skill helps identify problematic coupling patterns and provides actionable refactoring guidance.

## Core Principle

**Coupling is not inherently bad—misdesigned coupling is bad.** The goal is balanced coupling, not zero coupling. 

The fundamental formula:

```
MODULARITY = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY
```

A system achieves modularity when:
- High integration strength components are close together (same module/service)
- Low integration strength components can be far apart (different services)
- Low volatility components can tolerate coupling mismatches

## The Three Dimensions of Coupling

Always evaluate coupling across these three dimensions: 

### 1. Integration Strength (What knowledge is shared?)

From strongest (worst) to weakest (best):

| Level | Type | Description | Example |
|-------|------|-------------|---------|
| 1 | **Intrusive** | Using non-public interfaces | Direct database access to another service, reflection on private fields |
| 2 | **Functional** | Sharing business logic/rules | Same validation duplicated in two places, order-dependent operations |
| 3 | **Model** | Sharing domain models | Two services using identical entity definitions |
| 4 | **Contract** | Only explicit interfaces | Well-designed APIs, DTOs, protocols |

### 2. Distance (How far does knowledge travel?)

From closest to most distant:
1. Methods within same class
2. Classes within same file
3. Classes in same namespace/package
4. Modules in different namespaces
5. Separate services/microservices
6. Services owned by different teams
7. Different systems/organizations 

### 3. Volatility (How often will it change?)

Use Domain-Driven Design subdomain classification:
- **Core subdomains**: High volatility (competitive advantage, frequent changes)
- **Supporting subdomains**: Low volatility (necessary bu