class ReservationService {

  public function calculateTotal()
  {
      return $this->pricingService
          ->applySeasonModifier()
          ->applyDiscountRules()
          ->applyChannelCommission()
          ->applyTaxes()
          ->buildInvoice();
  }

}

// Domain rules evolve
// architecture decisions matter
// complexity grows over time
Volver a la Comparación

A02 — Repository Pattern

Capas de Servicio y Repository separan controladores del acceso a datos

Patrón: Service + Repository

Filosofía: Invierte dependencias, mantén controladores delgados, abstrae acceso a datos.

Descripción

A02 introduce una capa de servicio y el patrón repository. Los controladores delegan a servicios, los servicios contienen lógica de negocio, y los repositories abstraen el acceso a datos. Esto crea una clara separación de responsabilidades y mejora la testeabilidad.

Fortalezas:

  • Los controladores permanecen delgados (30 líneas) en todas las fases
  • Inversión de dependencias a través de interfaces
  • Los servicios son más fáciles de testear con repositories mockeados
  • Clara separación entre infraestructura y lógica
  • Buen equilibrio entre estructura y pragmatismo

Debilidades:

  • Toda la complejidad migra al 'Servicio Dios' (172 líneas)
  • El servicio sigue acoplado a detalles de implementación de lógica de negocio
  • Sin reducción en complejidad algorítmica
  • Añadir nuevas reglas de precio aún requiere modificar el servicio
  • La capa de servicio puede convertirse en un catch-all para lógica

Evolución a través de Fases

Fase Archivos Líneas de Código Controlador (líneas) Capa de Servicios (líneas)
Fase 01 10 269 29 72
Fase 02 10 407 30 120
Fase 03 10 503 30 143
Fase 04 10 587 30 172

Patrón God Service: El controlador se mantiene delgado (30 líneas) pero el servicio creció a 172 líneas manejando toda la lógica de precio. El patrón Repository desacopla el acceso a datos pero no reduce la complejidad algorítmica.

Métricas Clave

Total de Archivos

10

Estable entre fases

Total de Líneas de Código

587

+118% crecimiento P01→P04

Tamaño del Controlador (Fase 04)

30 líneas

+1 línea desde Fase 01

Puntuación de Testeabilidad

Media

Servicios testeables con mocks

Conclusión

El patrón Repository resuelve el problema equivocado.

Aunque desacopla el acceso a datos (¡bien!), no aborda el problema central: la complejidad algorítmica. Toda la lógica de precio sigue viviendo en un 'Servicio Dios' que maneja cada escenario de precio. Añadir nuevas reglas aún requiere modificar el servicio y entender todo su flujo de lógica.

A02 es mejor que A01, pero es una mejora táctica que no aborda el problema estructural de la complejidad creciente del dominio.

✓ Cuándo usar A02

  • Necesitas testeabilidad pero la lógica de dominio sigue siendo relativamente simple
  • El equipo se beneficia de una clara separación de responsabilidades
  • Dominio estable con cambios infrecuentes de reglas de negocio
  • Buen paso intermedio entre A01 y patrones más complejos
Volver a la Comparación Ver Código en GitHub