Fase 1: Estructura Base y DI Container - Clean Architecture

COMPLETADO: Fase 1 de la migración a Clean Architecture + POO

## Estructura de Carpetas
- ✓ Estructura completa de 4 capas (Domain, Application, Infrastructure, Presentation)
- ✓ Carpetas de Use Cases (SaveComponent, GetComponent, DeleteComponent, SyncSchema)
- ✓ Estructura de tests (Unit, Integration, E2E)
- ✓ Carpetas de schemas y templates

## Composer y Autoloading
- ✓ PSR-4 autoloading configurado para ROITheme namespace
- ✓ Autoloader optimizado regenerado

## DI Container
- ✓ DIContainer implementado con patrón Singleton
- ✓ Métodos set(), get(), has() para gestión de servicios
- ✓ Getters específicos para ComponentRepository, ValidationService, CacheService
- ✓ Placeholders que serán implementados en Fase 5
- ✓ Prevención de clonación y deserialización

## Interfaces
- ✓ ComponentRepositoryInterface (Domain)
- ✓ ValidationServiceInterface (Application)
- ✓ CacheServiceInterface (Application)
- ✓ Component entity placeholder (Domain)

## Bootstrap
- ✓ functions.php actualizado con carga de Composer autoloader
- ✓ Inicialización del DIContainer
- ✓ Helper function roi_container() disponible globalmente

## Tests
- ✓ 10 tests unitarios para DIContainer (100% cobertura)
- ✓ Total: 13 tests unitarios, 28 assertions
- ✓ Suite de tests pasando correctamente

## Validación
- ✓ Script de validación automatizado (48/48 checks pasados)
- ✓ 100% de validaciones exitosas

La arquitectura base está lista para la Fase 2.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -0,0 +1,101 @@
+# Arquitectura del Sistema - ROI Theme
+
+## Diagrama de Capas
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                    FRAMEWORKS & DRIVERS                  │
+│                     (WordPress, MySQL)                   │
+└─────────────────────────────────────────────────────────┘
+                            ▲
+                            │
+┌─────────────────────────────────────────────────────────┐
+│                  INFRASTRUCTURE LAYER                    │
+│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
+│  │ Repositories │  │  Controllers │  │   Services   │  │
+│  │  (WordPress) │  │    (AJAX)    │  │ (Validation) │  │
+│  └──────────────┘  └──────────────┘  └──────────────┘  │
+└─────────────────────────────────────────────────────────┘
+                            ▲
+                            │
+┌─────────────────────────────────────────────────────────┐
+│                  APPLICATION LAYER                       │
+│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
+│  │  Use Cases   │  │     DTOs     │  │  Interfaces  │  │
+│  │ (SaveComp)   │  │  (Request)   │  │ (Contracts)  │  │
+│  └──────────────┘  └──────────────┘  └──────────────┘  │
+└─────────────────────────────────────────────────────────┘
+                            ▲
+                            │
+┌─────────────────────────────────────────────────────────┐
+│                    DOMAIN LAYER                          │
+│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
+│  │   Entities   │  │Value Objects │  │  Interfaces  │  │
+│  │ (Component)  │  │(CompName)    │  │ (Repository) │  │
+│  └──────────────┘  └──────────────┘  └──────────────┘  │
+└─────────────────────────────────────────────────────────┘
+```
+
+## Reglas de Dependencia
+
+La **Regla de Dependencia** dice:
+
+> Las dependencias de código fuente deben apuntar **hacia adentro**, hacia políticas de más alto nivel.
+
+- **Dominio** no depende de nadie
+- **Aplicación** depende solo de Dominio
+- **Infraestructura** depende de Aplicación y Dominio
+- **Frameworks** son un detalle de Infraestructura
+
+## Capas Explicadas
+
+### 1. Domain Layer (Capa de Dominio)
+
+**Responsabilidad**: Lógica de negocio pura
+
+**Contiene**:
+- Entidades (Component)
+- Value Objects (ComponentName, ComponentConfiguration)
+- Interfaces de repositorios
+- Excepciones de dominio
+
+**NO contiene**:
+- Código de WordPress
+- Acceso a base de datos
+- Código de UI
+
+### 2. Application Layer (Capa de Aplicación)
+
+**Responsabilidad**: Casos de uso y orquestación
+
+**Contiene**:
+- Use Cases (SaveComponent, GetComponent)
+- DTOs (Request/Response objects)
+- Interfaces de servicios
+
+**NO contiene**:
+- Lógica de negocio (eso va en Dominio)
+- Detalles de implementación (eso va en Infraestructura)
+
+### 3. Infrastructure Layer (Capa de Infraestructura)
+
+**Responsabilidad**: Implementación de detalles técnicos
+
+**Contiene**:
+- Repositorios que usan WordPress/MySQL
+- Controllers (AJAX, REST)
+- Servicios (Validation, Cache)
+- Adaptadores de frameworks
+
+**Depende de**:
+- Application Layer (usa Use Cases)
+- Domain Layer (implementa interfaces)
+- WordPress
+
+## Ventajas de esta Arquitectura
+
+1. **Testeable**: Fácil de testear sin WordPress
+2. **Mantenible**: Separación clara de responsabilidades
+3. **Escalable**: Fácil agregar nuevos features
+4. **Independiente**: El dominio no depende de frameworks
+5. **Flexible**: Fácil cambiar implementaciones