Skip to main content
domain-identification-grouping 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).
설치로 이동 Skills Marketplace 커뮤니티가 만든 AI 스킬을 발견하고 탐색하세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/tech-leads-club/agent-skills --skill domain-identification-grouping명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Zip 다운로드 다운로드 중... Evaluate a repo agent harness (AGENTS.md, rules, skills, skill refs) for broken paths/commands, redundant instructions, and usefulness using a stack-agnostic dual-judge protocol with planted traps. HIGH PRIORITY questionnaires at top: Q1 optional docs, Q2 B/C budget before Track A (certainty/tokens). A always runs after Q2; B/C opt-in. ADRs/RFCs excluded from T2. Mixed apply uses 11-mixed-apply.md (KEEP/CUT). Use when the user says harness eval, harness-eval, harness debug, audit AGENTS.md, audit skills/rules, instruction audit, redundancy of agent instructions, usefulness of skills, Ship/Review/Hold/Slim/Keep-core for harness, or wants Track A/B/C harness evaluation. Do NOT use for harness setup or init, feature spec-driven work (tlc-spec-driven), or applying Ship/Slim trims unless the user explicitly asks after the report.
Feature planning and implementation with 4 adaptive phases (Specify, Design, Tasks, Execute). Auto-sizes depth by complexity. Writes testable requirements in EARS notation, atomic tasks, atomic Conventional Commits, and requirement traceability. Ships deterministic Python validation scripts so structural gates are enforced by code, not memory. Features an independent Verifier (author != verifier, evidence-or-zero), a discrimination sensor, a decision log (STATE.md), a test-coverage matrix, and a self-improving lessons layer. Stack-agnostic and tool-agnostic. Use when (1) planning features, (2) implementing with verification and atomic commits, (3) validating an implementation against a spec. Triggers on "specify feature", "discuss feature", "design", "tasks", "implement", "validate", "verify work", "UAT", "record decision", "pause work", "resume work". Do NOT use for pure architecture decomposition analysis or standalone technical design documents.
evolutionary-modular-architecture Guides design and implementation of evolutionary modular-monolith platforms with DDD (strategic + tactical), flat-by-aggregate organization, an Anti-Corruption Layer for vendor independence, a transactional outbox for events, smart resilience (backoff with jitter, circuit breakers, idempotency), and a polished architecture HTML document with elegant SVG diagrams. Use when designing a platform or backend, defining bounded contexts, organizing modules and folders, choosing monolith vs microservices, decoupling from an external service (ERP, storage, AI), making calls resilient, adding real-time push, picking a 2026 TypeScript stack (Nx, NestJS, React), or producing an architecture document or diagram. Also triggers on 'modular monolith', 'bounded contexts', 'flat-by-aggregate', 'ports and adapters', 'architecture diagram'. Do NOT use for simple CRUD, NestJS-only deep implementation (use nestjs-modular-monolith), or pure domain-model review (use tactical-ddd).
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
Identify Domains : Analyze business capabilities and component relationshipsGroup Components : Assign components to appropriate domainsValidate Groupings : Ensure components fit well in their domainsRefactor Namespaces : Align component namespaces with domainsCreate 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
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
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
