Arquitectura web: capas, límites y recorrido

1. Capas lógicas y tiers de despliegue no son lo mismo

Al terminar podrás dibujar el recorrido de una acción web, asignar cada decisión a su responsable y señalar dónde cambia la confianza. El modelo clásico separa presentación, proceso ydatos. Sigue siendo útil, pero una aplicación actual suele añadir entrega en el borde, servicios externos y trabajo asíncrono.

Una capa agrupa responsabilidades. Un tier indica dónde se ejecutan. Las tres capas pueden vivir en un único proceso, como en un monolito pequeño, o desplegarse en navegador, funciones, servicios y almacenes distintos. Separar conceptos evita concluir que «tres capas» exige «tres servidores».

2. Cliente y borde: interacción, entrega y primera recepción

El cliente es normalmente un navegador, aunque también puede ser una aplicación móvil o una herramienta. Presenta la interfaz, recoge acciones, mantiene estado visual y envía solicitudes. HTML crea la estructura, CSS la presenta y JavaScript añade comportamiento. El navegador también aplica su modelo de seguridad por origen, pero sigue estando bajo control del usuario: los datos, botones ocultos y validaciones del frontend pueden modificarse.

El borde es el primer conjunto de servicios cercano a Internet: CDN, terminación TLS, proxy inverso, balanceador y, cuando existe, WAF. Puede servir archivos estáticos desde caché, filtrar tráfico y repartir solicitudes entre orígenes. DNS ayuda a localizar el destino, pero no pertenece a la lógica de la aplicación ni transporta por sí mismo la petición HTTP.

3. Presentación web y aplicación: recibir no es decidir

La capa de presentación web traduce HTTP a una operación de la aplicación. Resuelve rutas, interpreta parámetros y contenido, negocia formatos y construye la respuesta. En un framework moderno puede renderizar HTML en el servidor, exponer una API o combinar ambas tareas. Su frontera natural termina cuando la pregunta deja de ser «¿cómo entra o sale este dato?» y pasa a ser «¿qué permite el negocio?».

La capa de aplicación o dominio ejecuta casos de uso y conserva invariantes: identifica al actor, autoriza la acción, calcula resultados, coordina transacciones y decide qué debe persistir. No debería depender de que la petición proceda de un botón concreto; la misma regla debe proteger una página, una API, una tarea programada o una llamada interna.

En un monolito estas responsabilidades pueden ser módulos del mismo despliegue. Separarlas en el código sigue siendo valioso: permite probar las reglas sin levantar toda la interfaz y evita repartir decisiones críticas entre controladores, componentes visuales y consultas aisladas.

4. Datos, integraciones y procesos asíncronos

La capa de datos conserva estado en bases relacionales o documentales, cachés, índices de búsqueda y almacenamiento de objetos. Una caché acelera una lectura, pero no se convierte automáticamente en la fuente de verdad. Documenta qué almacén es autoritativo para cada dato, su política de retención y cómo se recupera ante un fallo.

Un proveedor externo no confirma una operación crítica solo porque el navegador vuelva a una URL de éxito. Por ejemplo, un pago se concilia con una notificación autenticada del proveedor y una transición válida en la fuente de verdad. La interfaz representa ese estado; no lo crea por sí sola.

5. Sigue una petición de extremo a extremo

Usa una acción concreta: una persona abre su panel privado. El navegador resuelve el nombre y establece una conexión protegida; el borde recibe la solicitud; la presentación reconoce la ruta; la aplicación verifica sesión y permiso; la capa de datos recupera solo lo autorizado; la respuesta recorre el camino inverso. HTTP ofrece la interfaz común, aunque por debajo existan varios intermediarios y tecnologías.

Para diagnosticar, añade a cada paso una señal verificable: identificador de petición, estado HTTP, duración, consulta, evento de dominio o intento del worker. Una respuesta 502 sitúa el síntoma entre intermediarios; no demuestra por sí sola cuál servicio falló. Correlaciona señales antes de atribuir la causa.

6. Cada cruce es un límite de confianza

Un límite de confianza aparece cuando datos o decisiones pasan entre actores, procesos o sistemas con distinta autoridad. Marca como no confiable toda entrada del navegador, incluso si la interfaz la generó. Repite la verificación cuando un servicio llama a otro: estar en una red interna no concede confianza implícita.

1. Autentica la identidad: prueba quién o qué realiza la llamada con una credencial válida para ese receptor.
2. Autoriza la acción y el recurso: deniega por defecto y comprueba el permiso en cada solicitud, en el servidor.
3. Valida el dato en su contexto: tipo, tamaño y formato no sustituyen las reglas de negocio ni la codificación de salida.
4. Reduce privilegios: cada componente recibe las credenciales y datos mínimos durante el tiempo mínimo.
5. Registra decisiones: conserva actor, acción, recurso, resultado e identificador de correlación sin volcar secretos.

7. Construye una ficha que otra persona pueda revisar

Elige un solo caso de uso de tu aplicación: iniciar sesión, crear un pedido o publicar un documento. Dibuja primero actores, aplicaciones y almacenes; después añade el flujo. No empieces por funciones o clases: un mapa de contexto y unidades desplegables suele bastar para que desarrollo, operaciones y seguridad compartan el mismo modelo.

• □El mapa nombra personas, aplicaciones, almacenes y proveedores externos
• □Cada flecha indica qué dato o mensaje cruza, en qué dirección y con qué protocolo
• □Las capas lógicas están separadas de los procesos, funciones o máquinas donde se despliegan
• □Cada dato crítico tiene una fuente de verdad explícita
• □Autenticación y autorización se ejecutan server-side en cada entrada aplicable
• □Colas, reintentos, cachés y fallos parciales tienen un comportamiento conocido
• □Los registros permiten seguir una operación sin almacenar credenciales ni secretos
• □La ficha describe el sistema real y tiene una persona responsable de actualizarla

Glosario