Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
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
Scan Components: Identify components with common namespace patterns
Detect Shared Code: Find classes/files used across components
Analyze Functionality: Determine if functionality is truly common
Assess Coupling: Calculate coupling impact before consolidation
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):
## 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:
Examine functionality
Read source code of each component
Identify what each component does
Note similarities and differences
Assess consolidation feasibility
Are differences minor (configurable)?
Can differences be abstracted?
Is functionality truly the same?
Calculate coupling impact
Count incoming dependencies (afferent coupling) before consolidation
Estimate incoming dependencies after consolidation
Compare total coupling levels
Example Analysis:
## Functionality Analysis**Notification Components**:
- CustomerNotification: Sends billing notifications
- TicketNotification: Sends ticket assignment notifications
- SurveyNotification: Sends survey emails
**Similarities**: All send emails to customers
**Differences**: Email content/templates, triggers
**Consolidation Feasibility**: ✅ High
- Differences are in content, not mechanism
- Can be abstracted with templates/context
Phase 4: Assess Coupling Impact
Before recommending consolidation, analyze coupling:
Calculate current coupling
Count components using each notification component
Sum total incoming dependencies
Estimate consolidated coupling
Count components that would use consolidated component
Compare to current total
Evaluate coupling increase
Is consolidated component too coupled?
Does it create a bottleneck?
Is coupling increase acceptable?
Example Coupling Analysis:
## Coupling Impact Analysis**Before Consolidation**:
- CustomerNotification: Used by 2 components (CA = 2)
- TicketNotification: Used by 2 components (CA = 2)
- SurveyNotification: Used by 1 component (CA = 1)
-**Total CA**: 5
**After Consolidation**:
- Notification: Used by 5 components (CA = 5)
-**Total CA**: 5 (same!)
**Verdict**: ✅ No coupling increase, safe to consolidate
Phase 5: Recommend Consolidation Approach
Based on analysis, recommend approach:
Shared Service (if):
Functionality changes frequently
Complex operations
Needs independent scaling
Multiple deployment units will use it
Shared Library (if):
Stable functionality
Simple utilities
Compile-time dependency acceptable
No need for independent deployment
Component Consolidation (if):
Highly related functionality
Low coupling impact
Same deployment unit acceptable
Output Format
Common Domain Components Report
## Common Domain Components Found### Notification Functionality**Components**:
- services/customer/notification (2% - 1,433 statements)
- services/ticket/notification (2% - 1,765 statements)
- services/survey/notification (2% - 1,299 statements)
**Shared Classes**: SMTPConnection (used by all 3)
**Functionality Analysis**:
- All send emails to customers
- Differences: Content/templates, triggers
- Consolidation Feasibility: ✅ High
**Coupling Analysis**:
- Before: CA = 2 + 2 + 1 = 5
- After: CA = 5 (no increase)
- Verdict: ✅ Safe to consolidate
**Recommendation**: Consolidate into `services/notification`- Approach: Shared Service
- Expected Size: ~4,500 statements (5% of codebase)
- Benefits: Reduced duplication, easier maintenance
Consolidation Opportunities Table
## Consolidation Opportunities
| Common Functionality | Components | Current CA | After CA | Feasibility | Recommendation |
| -------------------- | ------------ | ---------- | -------- | ----------- | ----------------------------- |
| Notification | 3 components | 5 | 5 | ✅ High | Consolidate to shared service |
| Audit | 3 components | 8 | 12 | ⚠️ Medium | Consolidate, monitor coupling |
| Validation | 2 components | 3 | 3 | ✅ High | Consolidate to shared library |
Detailed Consolidation Plan
## Consolidation Plan### Priority: High**Notification Components** → `services/notification`**Steps**:
1. Create new `services/notification` component
2. Move common functionality from 3 components
3. Create abstraction for content/templates
4. Update dependent components to use new service
5. Remove old notification components
**Expected Impact**:
- Reduced code: ~4,500 statements consolidated
- Reduced duplication: 3 components → 1
- Coupling: No increase (CA stays at 5)
- Maintenance: Easier to maintain single component
### Priority: Medium**Audit Components** → `services/audit`**Steps**:
[Similar format]
**Expected Impact**:
- Coupling increase: CA 8 → 12 (monitor)
- Benefits: Reduced duplication
Analysis Checklist
Common Pattern Detection:
Scanned all component namespaces for common leaf nodes
Identified components with same ending names
Filtered out infrastructure patterns
Grouped similar components
Shared Class Detection:
Scanned imports/dependencies in each component
Identified classes used by multiple components
Classified as domain vs infrastructure
Documented shared class usage
Functionality Analysis:
Examined source code of common components
Identified similarities and differences
Assessed consolidation feasibility
Determined if differences can be abstracted
Coupling Assessment:
Calculated current coupling (CA) for each component
