refactor: move config module from domain to application layer

[Copilot]

✅ Move config module from domain to create command handler - COMPLETE

Successfully moved src/domain/config/ to src/application/command_handlers/create/config/ to align with DDD principles.

Changes Summary

Module relocation:

• Moved src/domain/config/ → src/application/command_handlers/create/config/
• Updated module declarations in src/domain/mod.rs and src/application/command_handlers/create/mod.rs

Import path updates:

• Application layer: 5 files (handler, errors, tests)
• Presentation layer: 4 files (config_loader, environment subcommand, errors, template subcommand)
• Testing utilities: 1 file (e2e tasks)
• Documentation: 20+ doc examples

Merge resolution:

• Merged changes from main branch (PR Standardize command module structure with handler.rs and subcommands folder #74)
• Fixed import path in new template.rs file created in merged PR

Verification ✅

• ✅ cargo build - compiles successfully
• ✅ cargo test --lib - all 1002 tests pass
• ✅ cargo run --bin linter clippy - no warnings
• ✅ cargo fmt - formatting correct
• ✅ Merge conflicts resolved successfully

Impact

This refactoring improves architecture by:

• ✅ DDD Compliance: Removed DTOs from domain layer
• ✅ Higher Cohesion: Config module now co-located with create command handler
• ✅ Clearer Boundaries: Domain layer remains pure business logic
• ✅ Better Discoverability: All create command code in one place
• ✅ No Breaking Changes: Internal refactoring only

Ready for Merge

All verification steps complete. Merge conflicts resolved. The refactoring successfully aligns the codebase with DDD principles while maintaining all existing functionality.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Move config module from domain to create command handler</issue_title>
<issue_description>## 📋 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
  </issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Move config module from domain to create command handler #75

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[josecelano]

@copilot After merging another PR we need to solve conflicts in this one.

[Copilot]

@copilot After merging another PR we need to solve conflicts in this one.

Merge conflicts resolved in commit ec977df. The main branch changes have been merged successfully, and I updated the import path in the new template.rs file from domain::config to application::command_handlers::create::config. All tests pass.

[josecelano]

ACK ec977df