Guía de Estudio: Arquitectura, Microarquitectura y Desarrollo de Sistemas en la Nube

Este documento constituye un material de estudio integral basado en la sesión académica sobre el diseño, implementación y organización de sistemas modernos de software. El contenido abarca desde la conceptualización de la arquitectura de software hasta la implementación técnica de capas, seguridad mediante API Gateways y diagramación técnica.

1. Introducción General

La arquitectura de software no es una visión única, sino un conjunto de perspectivas que dependen de la "distancia" o el nivel de detalle que se desee observar. Al igual que en la arquitectura civil, el diseño de un sistema requiere entender cómo interactúan las piezas de software entre sí para cumplir con objetivos de negocio, escalabilidad y mantenimiento.

El estudio de este tema permite transitar desde la comprensión de sistemas externos (macronivel) hasta la organización interna de carpetas y funciones de una API (microarquitectura), facilitando la creación de sistemas modulares y seguros.

2. Marco Conceptual: Niveles de Arquitectura

Para entender un sistema, es necesario definir el nivel de detalle en el que se está trabajando:

2.1. Arquitectura de Alto Nivel

Es la visión más lejana del sistema. Muestra la interacción entre sistemas completos y entidades externas.

• Ejemplo: La relación entre un banco, el usuario, la AFIP, el Veraz y un comercio. En este nivel, cada entidad se ve como una "caja negra".

2.2. Arquitectura de Detalle (Foco en el Sistema)

Se realiza un "doble clic" sobre un componente específico para ver sus partes internas.

• Ejemplo: Dentro del "Banco", identificar el Mobile Banking, el Backend del banco y sus conexiones con herramientas externas de monitoreo o analítica.

2.3. Microarquitectura

Se refiere a la organización interna de un proyecto o microservicio. Define cómo se estructuran las carpetas y cómo fluye la información dentro de una API específica (por ejemplo, una API de cuentas).

3. Desarrollo del Tema: El Modelo de Tres Capas

La microarquitectura más recomendada para servicios en la nube se basa en la separación de responsabilidades en tres capas lógicas. Esta división no es física, sino una forma de organizar el código para que sea mantenible y testeable.

3.1. Capa de Presentación (Rutas/Controladores)

Es el "contrato" de la API. Su función principal es recibir la información del mundo exterior y validar el formato.

• Responsabilidades:
  • Declarar rutas (endpoints).
  • Validar parámetros de entrada (ej. verificar si un ID es requerido).
  • Gestionar los códigos de respuesta HTTP (200 OK, 404 Not Found, 500 Error).
  • Llamar a la capa de negocio.

3.2. Capa de Lógica de Negocio (Servicios)

Es el "cerebro" de la aplicación. Aquí se procesan las reglas que definen el comportamiento del sistema.

• Responsabilidades:
  • Ejecutar cálculos y validaciones de negocio.
  • Coordinar el flujo de datos entre la presentación y el acceso a datos.
  • Garantizar que se cumplan las condiciones necesarias antes de guardar o modificar información.

3.3. Capa de Acceso a Datos (Repositorios)

Es la encargada exclusiva de interactuar con el almacenamiento persistente (bases de datos).

• Responsabilidades:
  • Realizar consultas (Select, Find).
  • Insertar o actualizar registros en la base de datos (Mongo, Postgres, etc.).
  • Abstraer la tecnología de la base de datos para que las otras capas no dependan de ella.

4. Relación entre Conceptos: Interfaces y Polimorfismo

Uno de los mayores beneficios de separar el código en capas es la capacidad de intercambiar implementaciones sin afectar el resto del sistema. Esto se logra mediante el uso de Interfaces.

Concepto	Explicación
Interfaz	Conjunto de métodos públicos (input/output) que define qué puede hacer una clase, sin decir cómo lo hace.
Abstracción	Permite que la capa de negocio llame a un "Repositorio de Usuarios" genérico.
Intercambiabilidad	Si el día de mañana se cambia la base de datos de MongoDB a PostgreSQL, solo se modifica el Repositorio; la capa de negocio sigue llamando al mismo método guardar() y el sistema funciona igual.

5. Seguridad y Comunicación: API Gateway y JWT

En arquitecturas de microservicios, la seguridad se centraliza para evitar redundancias y mejorar la eficiencia.

5.1. El Rol del API Gateway

El API Gateway actúa como un punto de entrada único. Es el encargado de:

1. Validar el JSON Web Token (JWT): Verifica la identidad del usuario una sola vez.
2. Actuar como Proxy: Redirige la petición al microservicio correspondiente (Usuarios, Materias, etc.).

5.2. Headers Custom (X-Headers)

Para pasar información del usuario (como su ID o correo) desde el Gateway hacia los servicios internos sin volver a validar el token, se utilizan los Headers X- (por ejemplo, X-User-ID).

• Nomenclatura: Por estándar, los headers creados por el desarrollador para información propia del proyecto comienzan con el prefijo X-.
• Seguridad: Los servicios internos no están expuestos a internet; solo el Gateway puede acceder a ellos, lo que garantiza que la información en los headers sea confiable.

6. Ejemplos Prácticos

6.1. Ejemplo de Flujo de Datos (Capa por Capa)

Imaginemos la búsqueda de un usuario:

1. Ruta (Presentación): Recibe el ID, valida que no sea nulo y llama al UsuarioService.buscar(id).
2. Servicio (Negocio): Valida si el usuario tiene permisos para ser buscado y llama al UsuarioRepository.find(id).
3. Repositorio (Datos): Ejecuta db.collection('users').find({id}) en MongoDB y devuelve el objeto.

6.2. Uso de Logos en Arquitectura

Para mejorar la claridad de los diagramas técnicos, se recomienda incluir logos de las tecnologías utilizadas:

• Frontend: Logo de React.
• Runtime: Logo de Node.js.
• Base de Datos: Logo de MongoDB o PostgreSQL.
• Hosting: Logo de Vercel o Railway.

7. Errores Comunes y Aclaraciones

• Funciones Extensas: Existe una regla de oro que indica que una función no debería superar las 10 líneas. Si es más larga, debe atomizarse (dividirse en funciones más pequeñas) para mejorar la reutilización y lectura.
• Acoplamiento Lógico: En proyectos simples, las capas a veces parecen estar acopladas (monocapa), pero para proyectos que crecerán, la separación es indispensable desde el inicio.
• Confusión con Carpetas: La arquitectura de carpetas (microarquitectura) debe reflejar las capas lógicas (carpetas de routes, services, repositories).
• Validación de Identidad: No se debe pedir el User ID por URL si ya está en el token, ya que es inseguro. El Gateway debe extraerlo del token y pasarlo por header.

8. Síntesis y Conclusiones

• La arquitectura se define por la distancia de observación: desde interacciones entre bancos hasta la estructura de una función.
• La separación en tres capas (Presentación, Negocio y Datos) permite la escalabilidad y el mantenimiento.
• El API Gateway centraliza la seguridad y distribuye la identidad del usuario mediante X-Headers.
• Las Interfaces permiten que el sistema sea independiente de la tecnología de base de datos elegida.
• La claridad en los Diagramas de Secuencia (usando herramientas como autoactivate) es vital para entender los ciclos de vida de un proceso.

9. Fechas Importantes y Avisos Académicos

Fecha	Evento / Tipo	Descripción
Martes 13 de Octubre	Clase Virtual / Asincrónica	El profesor tiene una implementación en producción. Es probable que no haya clase presencial/sincrónica.
Martes 13 de Octubre	Entrega de Avances	Se solicitará subir artefactos (diagrama de arquitectura, 2 o 3 diagramas de secuencia) como ejercicio de entrega.

• Nota: La fecha del 13 de octubre está sujeta a confirmación final según la agenda de producción del docente.
• Advertencia: No dejar las consultas para el final del cuatrimestre, ya que se generan filas de espera largas para las revisiones de proyectos.

10. Preguntas de Repaso

Básicas

1. ¿Cuáles son las tres capas de la microarquitectura y qué hace cada una?
2. ¿Para qué sirve el prefijo X- en un header de HTTP?
3. ¿Qué diferencia hay entre arquitectura de alto nivel y microarquitectura?

Intermedias

4. ¿Por qué es recomendable que el API Gateway sea el único que valide el JWT?
5. Explique cómo una interfaz ayuda a cambiar de MongoDB a PostgreSQL sin tocar la lógica de negocio.
6. ¿Qué sucede en un diagrama de secuencia si una flecha no tiene una respuesta de retorno?

Avanzadas

7. Analice la "regla de las 10 líneas" en funciones: ¿cómo afecta esto a la reutilización de código en un sistema de cálculos complejos?
8. Diseñe mentalmente el flujo de una petición desde una App Mobile hasta una base de datos, pasando por un API Gateway que inyecta un X-User-ID. ¿Qué capas atraviesa?

1. Video resumen

2. Infografía

3. Presentación