Break out subprojects

[rustyrazorblade]

There is a lot of infra code in here now and I think it would be good to take a step back and organize it.

Splitting services into a subproject would be a reasonable first step. Ideally, it could be published as it's own artifact so it can be used from other projects.

[rustyrazorblade]

@claude

[claude]

Claude finished @rustyrazorblade's task in 3m 4s —— View job

---

Architecture Analysis: Breaking Out Subprojects

• Gather context: explore project structure and services layer
• Understand dependencies between services and other modules
• Assess feasibility and complexity
• Provide a detailed plan and recommendation

---

Current State

The project has a core module in settings.gradle but it's essentially empty (contains only YamlDelegate.kt). All the substantive code lives in the root module:

• services/ — 47 files, ~13,800 lines (K8s, Cassandra, AWS, observability, Spark services)
• providers/ — 31 files, ~4,100 lines (AWS SDK wrappers, SSH, Docker)
• configuration/ — 18 files (ClusterState, Host, User, ServerType, etc.)
• events/ — EventBus + 28 domain event interfaces

The spark:* submodules are a good reference pattern for what a clean extraction looks like — they have their own build.gradle.kts, clear dependencies on the root module, and could theoretically be published independently.

---

Dependency Graph (Simplified)

commands → services → providers → AWS SDK / SSH / Docker
              ↓             ↓
         configuration   events/EventBus
              ↓
           (types: ClusterState, Host, User, ServerType)

Everything in services/ depends on configuration types. You can't extract services without also extracting (or co-locating) configuration.

---

Key Extraction Challenges

1. Configuration types are tightly coupled to services
ClusterState, Host, User, ServerType, CassandraVersion, etc. are used throughout nearly every service. These would need to move into core first before services can be extracted.

2. EventBus coupling
Every service emits typed domain events via EventBus. The event hierarchy (events/Event.kt, 28 sealed interfaces) would need to be part of the publishable artifact or decoupled behind a listener interface.

3. CommandExecutor spans layers
CommandExecutor depends on ClusterStateManager (configuration), BackupRestoreService (a service), and Context (CLI-specific). It blurs the line between command and service layers.

4. OutputHandler is CLI-specific
Some services still reference OutputHandler directly instead of going through EventBus. These would need to be cleaned up for a library-safe API.

5. ClusterS3Path naming (noted in existing code comments)
Should be renamed to ClusterStoragePath before publishing — the S3 assumption leaks an implementation detail.

---

Recommended Phased Approach

Phase 1: Populate core with shared types (lowest risk, prerequisite)
Move configuration/ types (ClusterState, Host, User, ServerType, etc.) and events/ into the core module. This is the foundation everything else depends on. core can already be published as a standalone artifact today — it just needs content.

Phase 2: Extract providers into their own modules (medium risk)

• providers:aws — AWS SDK wrappers, retry utilities, IAM/EC2/S3 low-level ops
• providers:ssh — SSH connection pooling and remote operations
• providers:docker — Docker client

These have fewer internal cross-dependencies and the Koin module pattern (AWSModule.kt, SSHModule.kt, DockerModule.kt) already partitions them cleanly.

Phase 3: Extract services as a module (higher risk)
Once core and the provider modules are extracted, services become extractable. They'd declare deps on core + the provider modules. The AWS-specific services (services/aws/) could be a separate services:aws module.

Phase 4: Decouple CLI concerns (enables publishing)
For services to be published and used from other projects, OutputHandler references need to be removed — all output should go through EventBus. Then consumers can register their own listeners.

---

Suggested Starting Point

The cleanest first PR would be: move configuration/ and events/ into core. This is:

• Low risk (no behavioral change, just moving files + updating imports)
• A necessary prerequisite for everything else
• Immediately useful — core could be published as a shared types library

Should I create a plan for that first step? Or do you want to start with a different phase?

---