Summary 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
Identify Domains : Analyze business capabilities and component relationships
Group Components : Assign components to appropriate domains
Validate Groupings : Ensure components fit well in their domains
Refactor Namespaces : Align component namespaces with domains
Create Domain Map : Visualize domain structure and component groupings
When to Use
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
Customer Domain : Customer profile, billing, support contractsTicketing Domain : Ticket creation, assignment, routing, completionReporting 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 :
services/billing/payment
services/billing/history
services/customer/profile
services/supportcontract
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:
Examine Component Responsibilities
Read component names and descriptions
Understand what each component does
Identify business capabilities
Look for Business Language
Group components by business vocabulary
Example: "billing", "payment", "invoice" → Financial domain
Example: "customer", "profile", "contract" → Customer domain
Identify Domain Boundaries
Where do business concepts change?
What are the distinct business areas?
How do components relate to business capabilities?
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:
Analyze Component Functionality
What business capability does it support?
What domain vocabulary does it use?
What other components does it relate to?
Check Component Relationships
Which components are frequently used together?
What are the dependencies between components?
Do components share data or workflows?
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 grouping
Handle Edge Cases
Components that don't fit clearly: Analyze more deeply
Components that fit multiple domains: Choose primary domain
Shared components: May belong to Shared domain
Example Component Grouping :
## Component Domain Assignment
### Ticketing Domain (ss.ticket)
- Ticket Shared (ss.ticket.shared)
- Ticket Maintenance (ss.ticket.maintenance)
- Ticket Completion (ss.ticket.completion)
- Ticket Assign (ss.ticket.assign)
- Ticket Route (ss.ticket.route)
- KB Maintenance (ss.ticket.kb.maintenance)
- KB Search (ss.ticket.kb.search)
- Survey (ss.ticket.survey)
### Customer Domain (ss.customer)
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
### Reporting Domain (ss.reporting)
- Reporting Shared (ss.reporting.shared)
- Ticket Reports (ss.reporting.tickets)
- Expert Reports (ss.reporting.experts)
- Financial Reports (ss.reporting.financial)
Phase 3: Validate Domain Groupings Ensure components fit well in their assigned domains:
Check Cohesion
Do components in domain share business language?
Are components frequently used together?
Do components have direct relationships?
Verify Boundaries
Are domain boundaries clear?
Do components belong to only one domain?
Are there components that don't fit anywhere?
Assess Completeness
Are all components assigned to a domain?
Are domains cohesive and well-formed?
Do domains represent distinct business capabilities?
Get Stakeholder Validation
Review domain groupings with product owners
Ensure domains align with business understanding
Get feedback on domain boundaries
Phase 4: Refactor Namespaces for Domain Alignment Align component namespaces with identified domains:
Compare Current vs Target Namespaces
Current: services/billing/payment
Target: services/customer/billing/payment
Change: Add .customer domain node
Identify Refactoring Needed
Which components need namespace changes?
What domain nodes need to be added?
Are there components already aligned?
Create Refactoring Plan
List components needing namespace changes
Specify target namespace for each
Prioritize refactoring work
Execute Refactoring
Update component namespaces
Update imports/references
Verify all references updated
Example Namespace Refactoring :
## Namespace Refactoring Plan
### Customer Domain Alignment
| Component | Current Namespace | Target Namespace | Action |
| ---------------- | ------------------- | --------------------------- | ------------- |
| Billing Payment | ss.billing.payment | ss.customer.billing.payment | Add .customer |
| Billing History | ss.billing.history | ss.customer.billing.history | Add .customer |
| Customer Profile | ss.customer.profile | ss.customer.profile | No change |
| Support Contract | ss.supportcontract | ss.customer.supportcontract | Add .customer |
### Ticketing Domain Alignment
| Component | Current Namespace | Target Namespace | Action |
| -------------- | ----------------- | ------------------------ | ----------- |
| KB Maintenance | ss.kb.maintenance | ss.ticket.kb.maintenance | Add .ticket |
| KB Search | ss.kb.search | ss.ticket.kb.search | Add .ticket |
| Survey | ss.survey | ss.ticket.survey | Add .ticket |
Phase 5: Create Domain Map Visualize domain structure and component groupings:
Create Domain Diagram
Show domains as boxes
Show components within each domain
Show relationships between domains
Document Domain Structure
List domains and their components
Describe domain responsibilities
Note domain boundaries
Create Domain Inventory
Table of domains and components
Component counts per domain
Size metrics per domain
┌─────────────────────────────────────┐
│ Ticketing Domain (ss.ticket) │
├─────────────────────────────────────┤
│ • Ticket Shared │
│ • Ticket Maintenance │
│ • Ticket Completion │
│ • Ticket Assign │
│ • Ticket Route │
│ • KB Maintenance │
│ • KB Search │
│ • Survey │
└─────────────────────────────────────┘
│
│ uses
▼
┌─────────────────────────────────────┐
│ Customer Domain (ss.customer) │
├─────────────────────────────────────┤
│ • Customer Profile │
│ • Billing Payment │
│ • Billing History │
│ • Support Contract │
└─────────────────────────────────────┘
## Output Format
### Domain Identification Report
```markdown
## Domain Identification
### Domain: Customer (ss.customer)
**Business Capability**: Manages customer relationships, billing, and support contracts
**Components**:
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
**Component Count**: 4
**Total Size**: ~15,000 statements (18% of codebase)
**Domain Cohesion**: ✅ High
- Components share customer-related vocabulary
- Components frequently used together
- Direct relationships between components
**Boundaries**:
- Clear separation from Ticketing domain
- Clear separation from Reporting domain
- Shared components (Notification) used by all domains
Component Domain Assignment Table ## Component Domain Assignment
| Component | Current Namespace | Assigned Domain | Target Namespace |
| ------------------ | --------------------- | --------------- | --------------------------------- |
| Customer Profile | ss.customer.profile | Customer | ss.customer.profile (no change) |
| Billing Payment | ss.billing.payment | Customer | ss.customer.billing.payment |
| Ticket Maintenance | ss.ticket.maintenance | Ticketing | ss.ticket.maintenance (no change) |
| KB Maintenance | ss.kb.maintenance | Ticketing | ss.ticket.kb.maintenance |
| Reporting Shared | ss.reporting.shared | Reporting | ss.reporting.shared (no change) |
Namespace Refactoring Plan ## Namespace Refactoring Plan
### Priority: High
**Customer Domain Alignment**
**Components to Refactor**:
1. Billing Payment: `ss.billing.payment` → `ss.customer.billing.payment`
2. Billing History: `ss.billing.history` → `ss.customer.billing.history`
3. Support Contract: `ss.supportcontract` → `ss.customer.supportcontract`
**Steps**:
1. Update namespace declarations in source files
2. Update import statements in dependent components
3. Update directory structure
4. Run tests to verify changes
5. Update documentation
**Expected Impact**:
- All customer-related components aligned under `.customer` domain
- Clearer domain boundaries
- Easier to identify domain components
Domain Map Visualization ## Domain Map
### Domain Structure
Customer Domain (ss.customer)
├── Customer Profile
├── Billing Payment
├── Billing History
└── Support Contract
Ticketing Domain (ss.ticket)
├── Ticket Shared
├── Ticket Maintenance
├── Ticket Completion
├── Ticket Assign
├── Ticket Route
├── KB Maintenance
├── KB Search
└── Survey
Reporting Domain (ss.reporting)
├── Reporting Shared
├── Ticket Reports
├── Expert Reports
└── Financial Reports
Admin Domain (ss.admin)
├── User Maintenance
└── Expert Profile
Shared Domain (ss.shared)
├── Login
└── Notification
Ticketing Domain
│ uses
├─→ Shared Domain (Login, Notification)
└─→ Customer Domain (Customer Profile)
Customer Domain
│ uses
└─→ Shared Domain (Login, Notification)
Reporting Domain
│ uses
├─→ Ticketing Domain (Ticket data)
├─→ Customer Domain (Customer data)
└─→ Shared Domain (Login)
Analysis Checklist
Implementation Notes
For Node.js/Express Applications Domains typically organized in services/ directory:
services/
├── customer/ ← Customer Domain
│ ├── profile/
│ ├── billing/
│ │ ├── payment/
│ │ └── history/
│ └── supportcontract/
├── ticket/ ← Ticketing Domain
│ ├── shared/
│ ├── maintenance/
│ ├── assign/
│ └── route/
└── reporting/ ← Reporting Domain
├── shared/
├── tickets/
└── experts/
For Java Applications Domains identified by package structure:
com.company.customer ← Customer Domain
├── profile
├── billing
│ ├── payment
│ └── history
└── supportcontract
com.company.ticket ← Ticketing Domain
├── shared
├── maintenance
├── assign
└── route
Domain Identification Strategies Strategy 1: Business Capability Analysis
Identify what business capabilities the system provides
Group components by capability
Example: "Customer Management" capability → Customer Domain
Strategy 2: Vocabulary Analysis
Identify business vocabulary used by components
Group components sharing same vocabulary
Example: Components using "billing", "payment", "invoice" → Financial Domain
Strategy 3: Relationship Analysis
Identify components frequently used together
Group components with strong relationships
Example: Components that share data/workflows → Same Domain
Strategy 4: Stakeholder Collaboration
Work with product owners/business analysts
Use their understanding of business areas
Validate domain boundaries with them
Fitness Functions After creating domains, create automated checks:
Domain Namespace Governance // Ensure components belong to correct domain
function validateDomainNamespaces(components, domainRules) {
const violations = []
components.forEach((comp) => {
const domain = identifyDomain(comp.namespace)
const expectedDomain = domainRules[comp.name]
if (domain !== expectedDomain) {
violations.push({
component: comp.name,
currentDomain: domain,
expectedDomain: expectedDomain,
namespace: comp.namespace,
})
}
})
return violations
}
Domain Boundary Enforcement // Prevent components from accessing other domains directly
function enforceDomainBoundaries(components) {
const violations = []
components.forEach((comp) => {
comp.imports.forEach((imp) => {
const importedDomain = identifyDomain(imp)
const componentDomain = identifyDomain(comp.namespace)
if (importedDomain !== componentDomain && importedDomain !== 'shared') {
violations.push({
component: comp.name,
domain: componentDomain,
importsFrom: imp,
importedDomain: importedDomain,
issue: 'Cross-domain direct dependency',
})
}
})
})
return violations
}
Best Practices
Do's ✅
Collaborate with business stakeholders to identify domains
Group components by business capability, not technical layers
Ensure domains represent distinct business areas
Validate domain boundaries with stakeholders
Refactor namespaces to align with domains
Create clear domain documentation
Use business language in domain names
Don'ts ❌
Don't create domains based on technical layers (services, controllers, models)
Don't force components into domains where they don't fit
Don't skip stakeholder validation
Don't create too many small domains (aim for 3-7 domains)
Don't create domains that are too large (monolithic domains)
Don't ignore components that don't fit (analyze why)
Don't skip namespace refactoring (critical for clarity)
Common Domain Patterns
Typical Domains in Business Applications
Customer Domain : Customer management, profiles, relationshipsProduct Domain : Product catalog, inventory, pricingOrder Domain : Order processing, fulfillment, shippingBilling Domain : Invoicing, payments, financial transactionsReporting Domain : Reports, analytics, dashboardsAdmin Domain : User management, system configurationShared Domain : Common functionality (login, notification, utilities)
Domain Size Guidelines
Small Domain : 2-4 componentsMedium Domain : 5-8 componentsLarge Domain : 9-15 componentsToo Large : >15 components (consider splitting)
Next Steps After creating component domains:
Apply Create Domain Services Pattern - Extract domains to separate servicesPlan Service Extraction - Create migration plan for domain servicesImplement Domain Services - Move domains to separately deployed servicesMonitor Domain Boundaries - Use fitness functions to enforce boundaries
Notes
Domains should represent business capabilities, not technical layers
Domain identification requires collaboration with business stakeholders
Namespace refactoring is critical for domain clarity
Domains prepare the codebase for service-based architecture
Well-formed domains make service extraction easier
Domain boundaries should be clear and well-documented
