de5fff4f5c
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>
5.0 KiB
5.0 KiB
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
- Testeable: Fácil de testear sin WordPress
- Mantenible: Separación clara de responsabilidades
- Escalable: Fácil agregar nuevos features
- Independiente: El dominio no depende de frameworks
- Flexible: Fácil cambiar implementaciones