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>
This commit is contained in:
FrankZamora
101
docs/ARCHITECTURE.md
Normal file
101
docs/ARCHITECTURE.md
Normal file
@@ -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
|
||||
103
docs/GIT-BRANCHING-STRATEGY.md
Normal file
103
docs/GIT-BRANCHING-STRATEGY.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Estrategia de Git Branching - ROI Theme Migration
|
||||
|
||||
## Modelo de Branching
|
||||
|
||||
Usaremos un modelo simplificado basado en **Git Flow** adaptado para esta migración.
|
||||
|
||||
## Estructura de Ramas
|
||||
|
||||
```
|
||||
main (producción)
|
||||
│
|
||||
└── migration/clean-architecture (rama principal de migración)
|
||||
│
|
||||
├── migration/fase-1-infrastructure
|
||||
├── migration/fase-2-database
|
||||
├── migration/fase-3-domain
|
||||
├── migration/fase-4-application
|
||||
├── migration/fase-5-infrastructure-layer
|
||||
├── migration/fase-6-components
|
||||
├── migration/fase-7-testing
|
||||
├── migration/fase-8-deprecation
|
||||
└── migration/fase-9-documentation
|
||||
```
|
||||
|
||||
## Reglas de Trabajo
|
||||
|
||||
### 1. Rama Principal de Migración
|
||||
|
||||
- **Nombre**: `migration/clean-architecture`
|
||||
- **Propósito**: Integrar todas las fases de la migración
|
||||
- **Protegida**: NO se pushea directamente a esta rama
|
||||
- **Base para**: Todas las ramas de fases individuales
|
||||
|
||||
### 2. Ramas de Fases
|
||||
|
||||
- **Naming**: `migration/fase-{número}-{nombre-descriptivo}`
|
||||
- **Flujo**:
|
||||
1. Crear desde `migration/clean-architecture`
|
||||
2. Desarrollar la fase completa
|
||||
3. Merge de vuelta a `migration/clean-architecture`
|
||||
4. Tag de versión (v{fase}.0.0)
|
||||
|
||||
## Workflow por Fase
|
||||
|
||||
```bash
|
||||
# 1. Asegurarse de estar en rama principal de migración
|
||||
git checkout migration/clean-architecture
|
||||
git pull origin migration/clean-architecture
|
||||
|
||||
# 2. Crear rama para nueva fase
|
||||
git checkout -b migration/fase-1-infrastructure
|
||||
|
||||
# 3. Trabajar en la fase
|
||||
git add .
|
||||
git commit -m "Descripción del cambio"
|
||||
|
||||
# 4. Al completar la fase
|
||||
git checkout migration/clean-architecture
|
||||
git merge --no-ff migration/fase-1-infrastructure -m "Merge Fase 1: Infrastructure Base"
|
||||
|
||||
# 5. Crear tag de versión
|
||||
git tag -a v1.0.0 -m "Fase 1 completada: Infrastructure Base"
|
||||
|
||||
# 6. Push (si hay repositorio remoto)
|
||||
git push origin migration/clean-architecture
|
||||
git push origin v1.0.0
|
||||
```
|
||||
|
||||
## Commits
|
||||
|
||||
### Formato de Mensajes
|
||||
|
||||
```
|
||||
Fase {número}: {Título corto}
|
||||
|
||||
- Cambio 1
|
||||
- Cambio 2
|
||||
- Cambio 3
|
||||
```
|
||||
|
||||
## Tags
|
||||
|
||||
### Convención de Versionado
|
||||
|
||||
- **Fase completada**: `v{fase}.0.0`
|
||||
- Ejemplo: `v1.0.0` (Fase 1 completada)
|
||||
- **Correcciones menores**: `v{fase}.{minor}.0`
|
||||
- **Hotfixes**: `v{fase}.{minor}.{patch}`
|
||||
|
||||
## Checklist Pre-Commit
|
||||
|
||||
- [ ] Código sigue estándares (`composer phpcs`)
|
||||
- [ ] Tests pasan (`composer test`)
|
||||
- [ ] No hay archivos de backup incluidos
|
||||
- [ ] No hay credenciales hardcodeadas
|
||||
- [ ] Mensaje de commit es descriptivo
|
||||
|
||||
## Checklist Pre-Merge
|
||||
|
||||
- [ ] Todos los tests de la fase pasan
|
||||
- [ ] Código sigue estándares PHPCS
|
||||
- [ ] Documentación actualizada
|
||||
- [ ] Tag de versión creado
|
||||
Reference in New Issue
Block a user