[refactor] Restore clean architecture dependency direction via ports and DI #110
Description
Enhancement Description
Remove application-layer imports of infrastructure and enforce inward dependencies via ports and DI wiring.
Scope type: Architecture boundary restoration and dependency hygiene
Background
The application layer currently imports infrastructure implementations directly in multiple locations, violating the Dependency Rule and making unit testing and implementation swapping difficult.
Scope
Remove direct infrastructure imports from application layer
- Files: internal/application/service.go
- Files: internal/application/devnet/export.go
- Files: internal/application/devnet/provision.go
- Files: internal/application/devnet/docker_deploy.go
Correct dependency direction for ports
- Files: internal/application/ports/provisioner.go (remove plugin dependency)
Wire implementations via DI
- Files: internal/di/** (or chosen container wiring)
- Files: internal/infrastructure/** (adapters implementing ports)
Add static enforcement (optional in this issue; may link to Issue 6.1)
- Files: .golangci.yml (depguard)
Non-Goals
- Re-architecting all modules beyond the identified violations
- Changing business logic behavior while moving dependencies
- Migrating DI container as part of this issue (handled separately)
Risks and Open Questions
- Refactor may reveal missing ports or poorly defined boundaries
- Risk of cyclic deps if adapters are not placed correctly
- Need to ensure tests can run with mocks/fakes once ports are cleaned up
Validation Plan
Unit and Integration Checks
- go test ./... with mocks for ports in application packages
- Static check: confirm internal/application does not import internal/infrastructure
- Lint run confirming depguard (if enabled)
End-to-End Checks
- Smoke: deploy/provision/export flows still execute via DI wiring
- Ensure no runtime nil dependency due to wiring mistakes
Evidence Required in Issue Updates
- grep/go list outputs showing removal of forbidden imports
- Example unit test demonstrating application use case with mocked ports
Acceptance Criteria
- internal/application has zero imports from internal/infrastructure
- Ports do not import plugin packages
- Infrastructure accessed only through ports
- Application unit tests runnable without real infrastructure
Deliverables
- PR updating imports and introducing/adjusting port interfaces
- PR updating adapters and DI wiring to match new ports