/domain-identification-grouping

name: domain-identification-grouping
description: Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

Domain Identification and Grouping

This skill groups architectural components into logical domains (business areas) to prepare for creating domain services in a service-based architecture.

How to Use

Quick Start

Request analysis of your codebase:

• **"Group components into logical domains"**
• **"Identify component domains for service-based architecture"**
• **"Create domain groupings from components"**
• **"Analyze which components belong to which domains"**

Usage Examples

**Example 1: Domain Identification**

User: "Group components into logical domains"

The skill will:
1. Analyze component responsibilities and relationships
2. Identify business domains based on functionality
3. Group components into domains
4. Create domain diagrams
5. Suggest namespace refactoring for domain alignment

**Example 2: Domain Analysis**

User: "Which domain should the billing components belong to?"

The skill will:
1. Analyze billing component functionality
2. Check relationships with other components
3. Identify appropriate domain (e.g., Customer or Financial)
4. Recommend domain assignment

**Example 3: Domain Refactoring**

User: "What namespace refactoring is needed to align components with domains?"

The skill will:
1. Compare current component namespaces to identified domains
2. Identify misaligned components
3. Suggest namespace changes
4. Create refactoring plan

Step-by-Step Process

1. **Identify Domains**: Analyze business capabilities and component relationships 2. **Group Components**: Assign components to appropriate domains 3. **Validate Groupings**: Ensure components fit well in their domains 4. **Refactor Namespaces**: Align component namespaces with domains 5. **Create Domain Map**: Visualize domain structure and component groupings

When to Use

Apply this skill when:

• After identifying, sizing, and analyzing component dependencies
• Before creating domain services (Pattern 6)
• When planning service-based architecture migration
• Analyzing component relationships and business alignment
• Preparing for domain-driven design implementation
• Grouping components for better organization

Core Concepts

Domain Definition

A **domain** is a logical grouping of components that:

• Represents a distinct business capability or area
• Contains related components that work together
• Has clear boundaries and responsibilities
• Can become a domain service in service-based architecture

**Examples**:

• **Customer Domain**: Customer profile, billing, support contracts
• **Ticketing Domain**: Ticket creation, assignment, routing, completion
• **Reporting Domain**: Ticket reports, expert reports, financial reports

Component Domain Relationship

**One-to-Many**: A single domain contains multiple components

Domain: Customer
├── Component: Customer Profile
├── Component: Billing Payment
├── Component: Billing History
└── Component: Support Contract

Domain Manifestation

Domains are physically manifested through **namespace structure**:

**Before Domain Alignment**:

services/billing/payment
services/billing/history
services/customer/profile
services/supportcontract

**After Domain Alignment**:

services/customer/billing/payment
services/customer/billing/history
services/customer/profile
services/customer/supportcontract

Notice how all customer-related functionality is grouped under `.customer` domain.

Analysis Process

Phase 1: Identify Business Domains

Analyze the codebase to identify distinct business domains:

1. **Examine Component Responsibilities**

• Read component names and descriptions
• Understand what each component does
• Identify business capabilities

2. **Look for Business Language**

• Group components by business vocabulary
• Example: "billing", "payment", "invoice" → Financial domain
• Example: "customer", "profile", "contract" → Customer domain

3. **Identify Domain Boundaries**

• Where do business concepts change?
• What are the distinct business areas?
• How do components relate to business capabilities?

4. **Collaborate with Business Stakeholders**

• Validate domain identification with product owners
• Ensure domains align with business understanding
• Get feedback on domain boundaries

**Example Domain Identification**:

## Identified Domains

1. **Ticketing Domain** (ss.ticket)
   - Ticket creation, assignment, routing, completion
   - Customer surveys
   - Knowledge base

2. **Customer Domain** (ss.customer)
   - Customer profile
   - Billing and payment
   - Support contracts

3. **Reporting Domain** (ss.reporting)
   - Ticket reports
   - Expert reports
   - Financial reports

4. **Admin Domain** (ss.admin)
   - User maintenance
   - Expert profile management

5. **Shared Domain** (ss.shared)
   - Login
   - Notification

Phase 2: Group Components into Domains

Assign each component to an appropriate domain:

1. **Analyze Component Functionality**

• What business capability does it support?
• What domain vocabulary does it use?
• What other components does it relate to?

2. **Check Component Relationships**

• Which components are frequently used together?
• What are the dependencies between components?
• Do components share data or workflows?

3. **Assign to Domain**

• Place component in domain that best fits its functionality
• Ensure component aligns with domain's business language
• Verify component relationships support domain grou