edge-connect-client/cmd/cli/main.go

57 lines
2.3 KiB
Go
Raw Normal View History

feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
package main
import (
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
"log"
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
"os"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/adapters/driven/edgeconnect"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/adapters/driving/cli"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/application/app"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/application/cloudlet"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/application/instance"
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/application/organization"
"edp.buildth.ing/DevFW-CICD/edge-connect-client/internal/infrastructure/edgeconnect_client"
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
)
func main() {
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
// Hexagonal Architecture Wiring
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
// 1. Infrastructure Layer: Create the low-level EdgeConnect client
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
baseURL := getEnvOrDefault("EDGE_CONNECT_BASE_URL", "https://console.mobiledgex.net")
username := os.Getenv("EDGE_CONNECT_USERNAME")
password := os.Getenv("EDGE_CONNECT_PASSWORD")
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
// Use a logger for the infrastructure client
logger := log.New(os.Stderr, "[edgeconnect-client] ", log.LstdFlags)
clientOpts := []edgeconnect_client.Option{
edgeconnect_client.WithLogger(logger),
}
var infraClient *edgeconnect_client.Client
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
if username != "" && password != "" {
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
infraClient = edgeconnect_client.NewClientWithCredentials(baseURL, username, password, clientOpts...)
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
} else {
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
infraClient = edgeconnect_client.NewClient(baseURL, clientOpts...)
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
}
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
// 2. Adapter Layer: Create the driven adapter, injecting the infrastructure client.
// This adapter implements the repository interfaces required by the application layer.
edgeConnectAdapter := edgeconnect.NewAdapter(infraClient)
// 3. Application Layer: Create services, injecting the adapter (which fulfills the repository port).
appService := app.NewService(edgeConnectAdapter)
instanceService := instance.NewService(edgeConnectAdapter)
cloudletService := cloudlet.NewService(edgeConnectAdapter)
organizationService := organization.NewService(edgeConnectAdapter)
refactor(arch): Separate infrastructure from driven adapter 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.
2025-10-09 00:47:45 +02:00
// 4. Driving Adapter (Presentation Layer): Execute the CLI, injecting the application services.
cli.ExecuteWithServices(appService, instanceService, cloudletService, organizationService)
feat: implement dependency injection with proper hexagonal architecture ✨ Features: - Simple dependency inversion following SOLID principles - Clean constructor injection without complex DI containers - Proper hexagonal architecture with driving/driven separation - Presentation layer moved to cmd/cli for correct application structure 🏗️ Architecture Changes: - Driving Adapters (Inbound): internal/adapters/driving/cli/ - Driven Adapters (Outbound): internal/adapters/driven/edgeconnect/ - Core Services: Dependency-injected via interface parameters - main.go relocated from root to cmd/cli/main.go 📦 Application Flow: 1. cmd/cli/main.go - Entry point and dependency wiring └── Creates EdgeConnect client based on environment └── Instantiates services with injected repositories └── Executes CLI with properly wired dependencies 2. internal/adapters/driving/cli/ - User interface layer └── Receives user commands and input validation └── Delegates to core services via driving ports └── Handles presentation logic and output formatting 3. internal/core/services/ - Business logic layer └── NewAppService(appRepo, instanceRepo) - Constructor injection └── NewAppInstanceService(instanceRepo) - Interface dependencies └── NewCloudletService(cloudletRepo) - Clean separation 4. internal/adapters/driven/edgeconnect/ - Infrastructure layer └── Implements repository interfaces for external API └── Handles HTTP communication and data persistence └── Provides concrete implementations of driven ports 🔧 Build & Deployment: - CLI Binary: make build → bin/edge-connect-cli - Usage: ./bin/edge-connect-cli --help - Tests: make test (all passing) - Clean: make clean (updated paths) 💡 Benefits: - Simple and maintainable dependency management - Testable architecture with clear boundaries - SOLID principles compliance without overengineering - Proper separation of concerns in hexagonal structure
2025-10-08 18:15:26 +02:00
}
func getEnvOrDefault(key, defaultValue string) string {
if value := os.Getenv(key); value != "" {
return value
}
return defaultValue
}