Strengthen Domain Invariant Enforcement (DDD Refactor)

[josecelano]

Overview

Apply the DDD validated constructor pattern to all domain configuration types, ensuring domain invariants are enforced at construction time rather than validated post-hoc.

Refactoring Plan

Full details documented in: docs/refactors/plans/strengthen-domain-invariant-enforcement.md

Related ADRs

• Validated Deserialization for Domain Types
• TryFrom for DTO to Domain Conversion

Reference Implementation

HttpApiConfig has been refactored as the reference implementation (Phase 0, Proposal #0). Use it as a template for remaining types.

Progress

Phase 0: Foundation (Complete ✅)

• Proposal 0: HttpApiConfig validated constructor
• Proposal 1: UdpTrackerConfig, HttpTrackerConfig, HealthCheckApiConfig validated constructors

Phase 1: Tracker Configuration Aggregate (In Progress 🔄)

• Proposal 2: TrackerConfig validates at construction
• Proposal 3: TrackerCoreConfig database validation

Phase 2: Cross-Cutting Invariants

• Proposal 4: UserInputs validated constructor (Grafana requires Prometheus)

Acceptance Criteria

• Tracker config types (UdpTrackerConfig, HttpTrackerConfig, HealthCheckApiConfig, HttpApiConfig) use validated constructors
• All fields are private with getter methods
• All types implement custom Deserialize with validation
• All DTO→Domain conversions use TryFrom trait
• Validation logic moved from application to domain layer
• Pre-commit checks pass: ./scripts/pre-commit.sh
• All remaining domain configuration types refactored (Phase 1-2)

Contributing Guide

See docs/contributing/ddd-practices.md for implementation patterns.