domain-driven-designlisted

# Domain-Driven Design (DDD) Skill This skill provides guidelines for organizing code following Domain-Driven Design principles. ## Core Principles 1. **Group by Domain, Not by Type** - Organize files by business domain rather than technical type 2. **Clear Boundaries** - Each domain has well-defined responsibilities 3. **Self-Documenting Structure** - Folder names clearly communicate what the code does 4. **Colocation** - Related code (components, utils, tests) lives together ## Domain Organization Rules ### ✅ DO - Create domain folders that match business concepts - Keep domain-specific utilities inside domain folders - Place tests in `__tests__/` subfolders within each domain - Use clear, descriptive folder names ### ❌ DON'T - Create generic folders like `src/helpers/`, `src/services/`, or `src/utils/` directly under `src/` (a scoped `src/lib/utils/` for minimal cross-domain primitives is allowed) - Mix different domain concerns in the same folder - Create folder hierarchies deeper than 3 levels below `src/` (e.g., `src/components/auth/login-form/` is allowed; `src/components/auth/login-form/subform/` is not) - Use abbreviations in folder names ## Project Structure ### Components Domain ```text src/components/ ├── auth/ # Authentication components │ ├── login-form/ │ ├── register-form/ │ └── password-reset/ ├── dashboard/ # Dashboard components │ ├── stats-card/ │ ├── activity-feed/ │ └── charts/ ├── checkout/