component-common-domain-detection

# Common Domain Component Detection

This skill identifies common domain functionality that is duplicated across multiple components and suggests consolidation opportunities to reduce duplication and improve maintainability.

## How to Use

### Quick Start

Request analysis of your codebase:

- **"Find common domain functionality across components"**
- **"Identify duplicate domain logic that should be consolidated"**
- **"Detect shared classes used across multiple components"**
- **"Analyze consolidation opportunities for common components"**

### Usage Examples

**Example 1: Find Common Functionality**

```
User: "Find common domain functionality across components"

The skill will:
1. Scan component namespaces for common patterns
2. Detect shared classes used across components
3. Identify duplicate domain logic
4. Analyze coupling impact of consolidation
5. Suggest consolidation opportunities
```

**Example 2: Detect Duplicate Notification Logic**

```
User: "Are there multiple notification components that should be consolidated?"

The skill will:
1. Find all components with notification-related names
2. Analyze their functionality and dependencies
3. Calculate coupling impact if consolidated
4. Recommend consolidation approach
```

**Example 3: Analyze Shared Classes**

```
User: "Find classes that are shared across multiple components"

The skill will:
1. Identify classes imported/used by multiple components
2. Classify as domain vs infrastructure functionality
3. Suggest consolidation or shared library approach
4. Assess impact on coupling
```

### Step-by-Step Process

1. **Scan Components**: Identify components with common namespace patterns
2. **Detect Shared Code**: Find classes/files used across components
3. **Analyze Functionality**: Determine if functionality is truly common
4. **Assess Coupling**: Calculate coupling impact before consolidation
5. **Recommend Actions**: Suggest consolidation or shared library approach

## When to Use

Apply this skill when:

- After identifying and sizing components (Pattern 1)
- Before flattening components (Pattern 3)
- When planning to reduce code duplication
- Analyzing shared domain logic across the codebase
- Preparing for component consolidation
- Identifying candidates for shared services or libraries

## Core Concepts

### Domain vs Infrastructure Functionality

**Domain Functionality** (candidates for consolidation):

- Business processing logic (notification, validation, auditing, formatting)
- Common to **some** processes, not all
- Examples: Customer notification, ticket auditing, data validation

**Infrastructure Functionality** (usually not consolidated here):

- Operational concerns (logging, metrics, security)
- Common to **all** processes
- Examples: Logging, authentication, database connections

### Common Domain Patterns

Common domain functionality often appears as:

1. **Namespace Patterns**: Components ending in same leaf node
   - `*.notification`, `*.audit`, `*.validation`, `*.formatting`
   - Example: `TicketNotification`, `BillingNotification`, `SurveyNotification`

2. **Shared Classes**: Same class used across multiple components
   - Example: `SMTPConnection` used by 5 different components
   - Example: `AuditLogger` used by multiple domain components

3. **Similar Functionality**: Different components doing similar things
   - Example: Multiple components sending emails with slight variations
   - Example: Multiple components writing audit logs

### Consolidation Approaches

**Shared Service**:

- Common functionality becomes a separate service
- Other components call this service
- Good for: Frequently changing logic, complex operations

**Shared Library**:

- Common code packaged as library (JAR, DLL, npm package)
- Components import and use the library
- Good for: Stable functionality, simple utilities

**Component Consolidation**:

- Merge multiple components into one
- Good for: Highly related functionality, low coupling impact

## Analysis Process

### Phase 1: Identify Common Namespace Patterns

Scan component namespaces for common leaf node names:

1. **Extract leaf nodes** from all component namespaces
   - Example: `services/billing/notification` → `notification`
   - Example: `services/ticket/notification` → `notification`

2. **Group by common leaf nodes**
   - Find components with same leaf node name
   - Example: All components ending in `.notification`

3. **Filter out infrastructure patterns**
   - Exclude: `.util`, `.helper`, `.common` (usually infrastructure)
   - Focus on: `.notification`, `.audit`, `.validation`, `.formatting`

**Example Output**:

```markdown
## Common Namespace Patterns Found

**Notification Components**:

- services/customer/notification
- services/ticket/notification
- services/survey/notification

**Audit Components**:

- services/billing/audit
- services/ticket/audit
- services/survey/audit
```

### Phase 2: Detect Shared Classes

Find classes/files used across multiple components:

1. **Scan imports/dependencies** in each component
   - Track which classes are imported from where
   - Note classes used by multiple components

2. **Identify shared classes**
   - Classes imported by 2+ components
   - Exclude infrastructure classes (Logger, Config, etc.)

3. **Classify as domain vs infrastructure**
   - Domain: Business logic classes (SMTPConnection, AuditLogger)
   - Infrastructure: Technical utilities (Logger, DatabaseConnection)

**Example Output**:

```markdown
## Shared Classes Found

**Domain Classes**:

- `SMTPConnection` - Used by 5 components (notification-related)
- `AuditLogger` - Used by 8 components (audit-related)
- `DataFormatter` - Used by 3 components (formatting-related)

**Infrastructure Classes** (exclude from consolidation):

- `Logger` - Used by all components (infrastructure)
- `Config` - Used by all components (infrastructure)
```

### Phase 3: Analyze Functionality Similarity

For each group of common components:

1. **Examine functionality**