La arquitectura multicapa

Una capa es una agrupación de código por responsabilidad: todo lo que hace un mismo tipo de trabajo va junto, y cada capa solo habla con la de al lado a través de un interfaz. La capa de presentación no sabe cómo están guardados los datos; la capa de persistencia no sabe si por encima hay una web, una aplicación de móvil o un proceso nocturno.

Un nivel físico es otra cosa: es una máquina o un grupo de máquinas donde se despliega el software. La confusión es constante porque en inglés se usan dos palabras distintas, layer para la capa lógica y tier para el nivel físico, y en castellano las dos se traducen por capa. Una aplicación de tres capas lógicas puede estar desplegada en un solo servidor, o repartida en cinco.

• Las capas se cuentan mirando el código y sus responsabilidades.
• Los niveles se cuentan mirando el diagrama de despliegue y las máquinas.
• Se puede subir de niveles sin tocar las capas: basta con mover a otra máquina una capa que ya estaba separada.
• Lo contrario no: si la lógica y la presentación están mezcladas en el mismo código, no se pueden desplegar por separado.

El número de capas es una decisión de diseño; el número de niveles, una decisión de despliegue. Separar bien las capas es lo que deja abierta la puerta a repartir los niveles después.

Es el cliente/servidor en su forma más simple: por un lado, un programa instalado en el equipo del usuario que pinta las pantallas y contiene las reglas de negocio; por otro, un gestor de base de datos que guarda y sirve los datos. El cliente se conecta directamente a la base de datos y le lanza consultas.

Funciona bien mientras haya pocos usuarios y las reglas cambien poco, y por eso fue el modelo dominante de las aplicaciones de escritorio corporativas. Sus límites aparecen en cuanto el sistema crece.

• Cada regla de negocio está repetida en todos los puestos, así que un cambio obliga a redistribuir la aplicación entera.
• Cada cliente abre su propia conexión contra la base de datos, y las conexiones son un recurso caro y limitado.
• La base de datos queda expuesta a todo el que tenga el programa y unas credenciales.
• Reutilizar esa lógica desde otro canal, por ejemplo una web o una aplicación de móvil, obliga a reescribirla.

La arquitectura de tres capas mete una capa intermedia entre la interfaz y los datos, y se lleva a ella toda la lógica de negocio. Es el modelo de referencia de las aplicaciones web y el que hay que saber describir de memoria.

En esta plataforma, por ejemplo, la presentación es la pantalla donde el opositor lee un subtema y contesta el test; la lógica de negocio decide si el test está aprobado, cuándo toca el siguiente repaso y qué subtema se desbloquea; y la persistencia guarda cada intento con su fecha y sus aciertos. Cambiar la fórmula del repaso espaciado toca solo la capa del medio.

La regla que distingue bien las capas: la presentación puede comprobar que un campo no está vacío, pero no puede decidir si un test está aprobado. Eso es negocio.

Hablar de n capas es admitir que tres no siempre bastan. Cuando el sistema crece, aparecen responsabilidades que no encajan limpiamente en ninguna de las tres y que merecen su propio sitio: la publicación de contenido estático, la seguridad perimetral, la integración con sistemas ajenos o la caché.

• Capa web o de publicación: sirve las páginas y los ficheros estáticos, y reparte la carga entre los servidores de aplicaciones.
• Capa de servicios o de integración: expone hacia fuera lo que el sistema ofrece, y habla con los sistemas de terceros. Aquí es donde encajan los servicios web.
• Capa de acceso a datos: aísla el dialecto concreto del gestor de base de datos del resto de la lógica.
• Capa transversal de seguridad, trazas y auditoría, que atraviesa a todas las demás.

El principio se mantiene: cada capa solo conoce a su vecina y se comunica con ella por un contrato. Añadir capas tiene un precio, porque cada salto suma latencia, código de traducción y una pieza más que administrar, así que se añaden cuando resuelven un problema real y no por simetría.

Separar en capas no hace que la aplicación vaya más rápida: de hecho la hace un poco más lenta, porque introduce saltos. Se hace por otras cinco razones, y conviene saber decirlas con sus palabras exactas.

• Escalabilidad: si el cuello de botella está en la lógica de negocio, se replica solo esa capa y se pone un balanceador delante, sin duplicar ni la base de datos ni la interfaz.
• Mantenimiento: un cambio queda confinado en una capa, y el resto del sistema no se entera mientras el contrato entre capas no varíe.
• Despliegue independiente: cada capa se versiona y se publica por su cuenta, y una parada para actualizar la interfaz no obliga a parar el resto.
• Reutilización: la misma lógica de negocio sirve a la web, a la aplicación de móvil y a una API pública, en vez de estar copiada tres veces.
• Seguridad: la base de datos deja de estar expuesta y solo la alcanza la capa que tiene derecho a hablar con ella, lo que reduce mucho la superficie de ataque.

Todas las ventajas dependen de una sola condición: que el contrato entre capas sea estable y que ninguna capa se salte a su vecina para ir por atajo a la siguiente.