Revision de Arquitectura

El Problema

Las decisiones de arquitectura se acumulan con el tiempo. Un modulo fuertemente acoplado que parece inofensivo con 500 lineas se convierte en un monolito inmantenible con 5,000. Los equipos entregan funcionalidades sin evaluar la direccion de dependencias, los limites de abstraccion o si el principio de responsabilidad unica realmente se cumple. Cuando el dolor arquitectonico se manifiesta, los costos de refactorizacion se han multiplicado por diez.

El Prompt

Revisa la arquitectura del siguiente codigo. Actua como un ingeniero principal evaluando el sistema para escalabilidad y mantenibilidad a largo plazo.

CONTEXTO: [ej. "Servicio de checkout e-commerce, 3 desarrolladores, Node.js/Express"]
ESTRUCTURA DE ARCHIVOS:
[pegar arbol de directorios o rutas clave]

CODIGO:
[pegar modulos/archivos clave]

Evalua en estas dimensiones arquitectonicas:

1. **Cumplimiento SOLID**
   - Responsabilidad Unica: Cada modulo/clase tiene un solo motivo de cambio?
   - Abierto/Cerrado: Se puede extender comportamiento sin modificar codigo existente?
   - Sustitucion de Liskov: Los subtipos son realmente intercambiables?
   - Segregacion de Interfaces: Las interfaces son esbeltas o infladas?
   - Inversion de Dependencias: Los modulos de alto nivel dependen de abstracciones?

2. **Analisis de Acoplamiento**
   - Mapear dependencias entre modulos. Identificar dependencias circulares.
   - Clasificar acoplamiento: fuerte (refs directas) / debil (interfaces/eventos) / ninguno.
   - Marcar God Objects que saben demasiado sobre otros modulos.

3. **Evaluacion de Cohesion**
   - Cada modulo agrupa funcionalidad relacionada?
   - Identificar riesgos de shotgun surgery (un cambio toca 5+ archivos).

4. **Limites de Abstraccion**
   - Son claros los limites de capas (controller → service → repository)?
   - La logica de negocio se filtra a capas de transporte o persistencia?
   - Los asuntos transversales (auth, logging, validacion) estan centralizados?

5. **Preparacion para Evolucion**
   - Que tan doloroso seria cambiar la base de datos? El framework?
   - Identificar vendor lock-in o acoplamiento al framework.

Para cada hallazgo, proporciona:
- **Ubicacion**: Modulo/archivo afectado
- **Severidad**: deuda-estructural / design-smell / mejora
- **Impacto**: Que se rompe o degrada al crecer el codigo
- **Recomendacion**: Refactorizacion concreta con bosquejo antes/despues

Ejemplo de Salida

## Revision de Arquitectura: Servicio de Checkout

### Deuda Estructural: Patron God Service
Ubicacion: `src/services/OrderService.ts` (847 lineas)
Impacto: Maneja pagos, inventario, email y analytics — cualquier cambio arriesga efectos secundarios.
Recomendacion: Dividir en PaymentService, InventoryService, NotificationService.
OrderService se convierte en orquestador:

  async createOrder(dto: CreateOrderDTO) {
    const payment = await this.paymentService.charge(dto);
    await this.inventoryService.reserve(dto.items);
    await this.notificationService.sendConfirmation(payment);
  }

### Design Smell: Dependencia Circular
Ubicacion: UserModule <-> OrderModule (se importan mutuamente)
Recomendacion: Extraer tipos compartidos a un paquete `@shared/types`. Usar event bus para comunicacion entre modulos.

Cuando Usar

Ejecutar al iniciar una nueva fase del proyecto, al incorporarse a un codigo heredado, o antes de una funcionalidad grande que estresara los limites existentes. Las revisiones de arquitectura son mas valiosas antes de que el codigo duplique su tamano — revelan las grietas que se convertiran en abismos.

Tips Pro

• Incluir el arbol de archivos — los problemas de arquitectura viven en las relaciones entre archivos, no dentro de ellos.
• Revisar en los limites — enfocarse en como los modulos se comunican, no en su implementacion interna.
• Pedir un grafo de dependencias — solicitar “Dibuja un grafo ASCII mostrando las relaciones entre modulos.”
• Combinar con escenarios de evolucion — agregar “Como manejaria esta arquitectura agregar GraphQL junto a REST?”