Move config module from domain to create command handler

[josecelano]

📋 Overview

Move the src/domain/config/ module to src/application/command_handlers/create/config/ to align with DDD principles and improve code organization.

Current Location (Incorrect):

src/domain/config/

Target Location (Correct):

src/application/command_handlers/create/config/

🎯 Problem

The config module is currently misplaced in the domain layer, violating Domain-Driven Design principles:

1. Serialization concerns in domain: Uses serde::Deserialize for JSON parsing (data transfer concern, not business logic)
2. Infrastructure operations in domain: Contains generate_template_file() with tokio::fs I/O operations
3. String-based primitives: Uses raw String types instead of domain value objects (EnvironmentName, Username)
4. Acts as DTO: Converts external formats to domain types via to_environment_params() - this is application layer responsibility
5. Low cohesion: Exclusively used by create command but separated from it by layer boundaries

✅ Solution

Move config module to be nested under the create command handler for:

• ✅ DDD compliance: Removes DTOs from domain layer
• ✅ Higher cohesion: Config lives with its only consumer
• ✅ Clearer boundaries: Domain remains pure business logic
• ✅ Better discoverability: All create command code in one place
• ✅ No premature abstraction: No generic dto/ folder for single use

📚 Documentation

Full refactoring plan with detailed implementation checklist:
👉 docs/refactors/plans/move-config-to-create-command.md

📝 Implementation Steps

The plan includes 9 major steps:

1. Create new directory structure
2. Move all 4 files (mod.rs, environment_config.rs, ssh_credentials_config.rs, errors.rs)
3. Update module declarations
4. Update imports in application layer (5 files)
5. Update imports in presentation layer (3 files)
6. Update imports in testing utilities (1 file)
7. Update documentation and doc examples
8. Clean up old directory
9. Comprehensive verification (build, test, lint, doc)

🧪 Testing

• All existing tests must continue to pass
• No behavior changes, only import path updates
• Verification includes: cargo build, cargo test, linters, documentation

🏗️ Architecture

This refactoring aligns with the project's DDD architecture where:

• Domain Layer: Pure business logic, entities, value objects
• Application Layer: Use cases, command handlers, DTOs
• Presentation Layer: CLI, user interaction, config loading
• Infrastructure Layer: External tools, file system, SSH

The config module is a DTO layer for the create command use case, hence belongs in application layer.

⏱️ Estimated Effort

Time: 1-2 hours
Complexity: Medium (multiple file moves, import updates)
Risk: Low (no behavior changes, only structural)

🔗 Related

• Development Principles
• DDD Architecture