Comparación de Arquitecturas: Sistema de Reservas
4 arquitecturas. 4 fases de creciente complejidad. Mismo dominio.
El Experimento
Este es un laboratorio práctico que explora cómo diferentes enfoques arquitectónicos responden al aumento de la complejidad del dominio. La misma lógica empresarial se implementa de cuatro formas distintas, cada una abordando el mismo problema con filosofías de diseño diferentes.
¿Cómo se comporta tu arquitectura cuando el dominio se vuelve complejo?
A01 — Monolithic Eloquent
Active Record / Monolito
Philosophy: Uso directo del ORM, lógica en modelos y controladores.
Strength: Más rápido de comenzar, mínimo boilerplate.
A02 — Repository Pattern
Service + Repository
Philosophy: Separación de responsabilidades con capa de servicios.
Strength: Mejor testeabilidad mediante inyección de dependencias.
A03 — Strategy Polymorphism
Strategy Pattern + Polimorfismo
Philosophy: Encapsular comportamientos a través del polimorfismo de objetos.
Strength: Modelo de dominio más expresivo.
A04 — Decorator Domain
Builder + Decorator Pattern
Philosophy: Componer comportamientos dinámicamente sin modificación.
Strength: Escala horizontalmente con nuevas reglas.
Dominio & Endpoints
Sistema de reservas hoteleras con creciente complejidad de reglas empresariales a través de 4 fases.
Endpoints Compartidos
| Method | Endpoint | Description |
|---|---|---|
| POST | /api/{arch}/v{phase}/reservation | Crear reserva |
| GET | /api/{arch}/v{phase}/reservation/{id} | Obtener reserva |
Prefijos URL por Arquitectura
| URL Prefix | Architecture |
|---|---|
| /api/arch_01/ | Monolithic Eloquent |
| /api/arch_02/ | Repository Pattern |
| /api/arch_03/ | Strategy + Polimorfismo |
| /api/arch_04/ | Decorator Domain |
Fases de Evolución
La complejidad del dominio aumenta progresivamente en 4 fases
Fase 01: Cálculo Base
Precio por noche, extras por noche/estancia
Fase 02: Reglas Condicionales
Descuentos por volumen (7/14 noches), promo combinada, precio mínimo, validación spa
Fase 03: Comportamiento Polimórfico
Impuestos hoteleros/eventos, comisiones, restricción de 3 noches para eventos
Fase 04: Reglas Componibles
Early booking (30/60 días), recargo de temporada (temporada alta/baja)
Mapa de Compromisos Arquitectónicos
¿Dónde se sitúa cada arquitectura en el espacio de simplicidad vs fragilidad? El ideal es abajo-izquierda (simple Y robusto), pero la realidad obliga a hacer compromisos.
¿Dónde se sitúa cada arquitectura en el espacio de simplicidad vs fragilidad? El ideal es abajo-izquierda (simple Y robusto), pero la realidad obliga a hacer compromisos.
🏆 Rankings Finales
| Criterion | 🥇 Gold | 🥈 Silver | 🥉 Bronze | ❌ Worst |
|---|---|---|---|---|
| Simplicidad | A01 (6 archivos) | A02 (10) | A03 (14) | A04 (22) |
| Controlador Delgado | A02/A03/A04 (30-32) | — | — | A01 (184) |
| Servicio Delgado | A04 (99+152) | A03 (123) | A02 (172) | A01 (184) |
| Testeabilidad | A04 (dominio puro) | A03 (estrategia) | A02 (servicio) | A01 (requiere BD) |
| Extensibilidad | A04 (nuevo Decorator) | A03 (nueva Strategy) | A02 (modificar servicio) | A01 (modificar controlador) |
| Fragilidad | A04 (baja) | A03 (media) | A02 (media-alta) | A01 (alta) |
⚡ Cuándo Usar Cada Una
Selección de arquitectura basada en las características de tu dominio
Dominio estable, sin cambios de reglas
→ A01 o A02
Tipos de producto con diferentes fórmulas
→ A03
Reglas de precio que cambian frecuentemente
→ A04
💡 Conclusiones Clave
A01: La simplicidad tiene coste exponencial
El controlador creció de 83 a 184 líneas en un único método manejando 13 responsabilidades. El monto del descuento de early booking se analiza desde la cadena discount_reason (str_starts_with + explode) — un hack frágil.
A02: Problema del Servicio Dios
El controlador se mantiene en 30 líneas pero toda la complejidad se trasladó a un 'Servicio Dios' de 172 líneas. El patrón Repository desvincula infraestructura pero no reduce complejidad algorítmica.
A03: Duplicación de estrategias
Phase04PricingStrategy duplica toda la lógica de BasicPricingStrategy solo para añadir 3 métodos. Buen equilibrio pero necesita refactorización para evitar duplicación de estrategias por fase.
A04: Escalabilidad horizontal
Mayor coste inicial (22 archivos, 1139 líneas) pero escala horizontalmente: cada nueva regla es un nuevo archivo Decorator, no código modificado. Builder + Decorator significa que Fase 05 apenas toca código existente.