Moves the `domain` and `ports` packages from `internal/core` to `internal`.
This refactoring simplifies the directory structure by elevating the core architectural concepts of domain and ports to the top level of the `internal` directory. The `core` directory is now removed as its only purpose was to house these two packages.
All import paths across the project have been updated to reflect this change.
This commit introduces a significant architectural refactoring to decouple the driven adapter from low-level infrastructure concerns, adhering more strictly to the principles of Hexagonal Architecture.
Problem:
The driven adapter in `internal/adapters/driven/edgeconnect` was responsible for both adapting data structures and handling direct HTTP communication, authentication, and request/response logic. This violated the separation of concerns, making the adapter difficult to test and maintain.
Solution:
A new infrastructure layer has been created at `internal/infrastructure`. This layer now contains all the low-level details of interacting with the EdgeConnect API.
Key Changes:
- **New Infrastructure Layer:** Created `internal/infrastructure` to house components that connect to external systems.
- **Generic HTTP Client:** A new, generic `edgeconnect_client` was created in `internal/infrastructure/edgeconnect_client`. It is responsible for authentication, making HTTP requests, and handling raw responses. It has no knowledge of the application's domain models.
- **Config & Transport Moved:** The `config` and `http` (now `transport`) packages were moved into the infrastructure layer, as they are details of how the application is configured and communicates.
- **Consolidated Driven Adapter:** The logic from the numerous old adapter files (`apps.go`, `cloudlet.go`, etc.) has been consolidated into a single, true adapter at `internal/adapters/driven/edgeconnect/adapter.go`.
- **Clear Responsibility:** The new `adapter.go` is now solely responsible for:
1. Implementing the driven port (repository) interfaces.
2. Translating domain models into the data structures required by the `edgeconnect_client`.
3. Calling the `edgeconnect_client` to perform the API operations.
4. Translating the results back into domain models.
- **Updated Dependency Injection:** The application's entry point (`cmd/cli/main.go`) has been updated to construct and inject dependencies according to the new architecture: `infra_client` -> `adapter` -> `service` -> `cli_command`.
- **SDK & Apply Command:** The SDK examples and the `apply` command have been updated to use the new adapter and its repository methods, removing all direct client instantiation.
Addresses Verbesserungspotential 2 (Error Handling uneinheitlich) by introducing
a comprehensive, structured error handling approach across all architectural layers.
## New Domain Error System
- Add ErrorCode enum with 15 semantic error types (NOT_FOUND, VALIDATION_FAILED, etc.)
- Implement DomainError struct with operation context, resource identifiers, and regions
- Create resource-specific error constructors (NewAppError, NewInstanceError, NewCloudletError)
- Add utility functions for error type checking (IsNotFoundError, IsValidationError, etc.)
## Service Layer Enhancements
- Replace generic fmt.Errorf with structured domain errors in all services
- Add comprehensive validation functions for App, AppInstance, and Cloudlet entities
- Implement business logic validation with meaningful error context
- Ensure consistent error semantics across app_service, instance_service, cloudlet_service
## Adapter Layer Updates
- Update EdgeConnect adapters to use domain errors instead of error constants
- Enhance CLI adapter with domain-specific error checking for better UX
- Fix SDK examples to use new IsNotFoundError() approach
- Maintain backward compatibility where possible
## Test Coverage
- Add comprehensive error_test.go with 100% coverage of new error system
- Update existing adapter tests to validate domain error types
- All tests passing with proper error type assertions
## Benefits
- ✅ Consistent error handling across all architectural layers
- ✅ Rich error context with operation, resource, and region information
- ✅ Type-safe error checking with semantic error codes
- ✅ Better user experience with domain-specific error messages
- ✅ Maintainable centralized error definitions
- ✅ Full hexagonal architecture compliance
Files modified: 12 files updated, 2 new files added
Tests: All passing (29+ test cases with enhanced error validation)
- Add edge-connect apply command with -f/--file and --dry-run flags
- Integrate config parser, deployment planner, and resource manager
- Provide comprehensive error handling and progress reporting
- Support deployment confirmation prompts and result summaries
- Move internal packages to public SDK packages for CLI access
- Update all tests to pass with new package structure
- Complete Phase 4 CLI Command Implementation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Phase 2 Complete: Deployment Planning
- Add comprehensive deployment plan types with action tracking
- Implement EdgeConnectPlanner with state comparison logic
- Support manifest hash calculation and change detection
- Add parallel infrastructure target planning
- Create deployment summary generation with duration estimates
- Include comprehensive test coverage with mock scenarios
- Handle API errors and edge cases gracefully
Features:
- Smart comparison of current vs desired state
- Minimal API calls through batched queries
- Support for dry-run planning operations
- Detailed deployment summaries with resource counts
- Extensible action types (CREATE, UPDATE, DELETE, NONE)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add comprehensive YAML configuration types for EdgeConnectConfig
- Implement robust parser with validation and path resolution
- Support both k8sApp and dockerApp configurations
- Add comprehensive test coverage with real example parsing
- Create validation for infrastructure uniqueness and port ranges
- Generate instance names following pattern: appName-appVersion-instance
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Enhanced comprehensive example to wait for AppInstance deployment completion:
## New Polling Features:
- **State Monitoring**: Polls ShowAppInst every 10 seconds until ready
- **Timeout Protection**: 5-minute maximum wait time with context cancellation
- **Smart State Detection**: Handles Creating, Ready, Running, Error states
- **Progress Feedback**: Real-time status updates during deployment
## Implementation Details:
- **waitForInstanceReady()**: Robust polling function with timeout
- **State Logic**: Exits on non-creating states (Ready, Running, Error)
- **Error Handling**: Distinguishes between polling errors and failure states
- **Context Management**: Proper timeout context with cleanup
## User Experience:
```
5️⃣ Waiting for application instance to be ready...
Polling instance state (timeout: 5 minutes)...
📊 Instance state: Creating
📊 Instance state: Creating (power: PowerOn)
📊 Instance state: Ready (power: PowerOn)
✅ Instance reached ready state: Ready
```
This ensures the example demonstrates a complete, realistic deployment
workflow where instance creation is fully completed before proceeding
to subsequent operations.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
