Architectura por capas — la que usamos por defecto

Desde mis inicios como desarrollador de software revisé aplicaciones que usan arquitectura en capas con un ojo crítico, también las he enjuiciado, evitado y escuchado los malos comentarios sobre su uso y cómo produce código spaghetti hasta sus problemas con la escalabilidad y tolerancia a fallos.

Sin embargo, a medida que pasa el tiempo, he reconocido y valorado más sus características aprendiendo sobre su funcionamiento ¿Por qué no es tan querida por algunos?

La arquitectura por capas

En una arquitectura por capas (Layered Architecture Style en inglés)(Layered Architecture Style en inglés) separamos el código según preocupaciones técnicas, cada una puede ser un componente y contener módulos (separación lógica de código) con un contrato API definida.

Podemos usar 2 capas en una aplicación cliente servidor, 3 capas o N capas (multi-layered architecture) con sus variaciones según las necesidades. Una separación muy usada es la capa de presentación, negocio, persistencia y base de datos, cada una con sus responsabilidades.

Una capa es independiente, aislada en el sistema e interactúa con otras usando una interfaz bien definida. Por ejemplo:

• Capa de presentación para la renderización de html o un punto de entrada para un servicio.
• Capa de negocio que contiene reglas de uso, fórmulas u otra particularidad de la aplicación.
• Capa de infraestructura que contiene un ORM que mapea una estructura hacia la base de datos y viceversa.
• Capa de base de datos que comúnmente se encuentra afuera de la aplicación.
• También puede haber una capa de servicio o core con funciones comunes que pueden ser usadas por algunos otros componentes o capas.

Cada aplicación puede tener el número de capas que necesite con sus responsabilidades llegando a una arquitectura de múltiples capas.

El concepto layers of isolation alinea que cada capa sea independiente y lo relevante permanezca dentro de ésta. Así, cuando se necesita cambiar la estructura de la presentación de un html, sólo modificamos esa parte sin afectar a las otras capas.

Flujos e interacción entre capas

La interacción entre las capas también se encuentra restringida para evitar que la capa de presentación (en un browser) pueda acceder directamente a la base de datos, en caso que siempre queramos evitarlo. Por eso cada una puede ser cerrada (closed) o abierta (open).

Una capa cerrada solamente puede interactuar con la capa superior e inferior directamente. Esa definición busca controlar qué capa afectamos cuando hacemos cambios en una. Usando el diagrama del ejemplo, sabemos que una modificación en la API de la capa de presentación afectará a la capa de negocio, y no nos tenemos que preocupar de las demás.

La capa abierta provee la opción de evitar que se use la capa del siguiente nivel directamente. Personalmente no recomiendo el uso de esas capas, pero puede justificarse. Por ejemplo, cuando tenemos funcionalidades comunes que pueden ser usadas directamente desde diferentes capas. En fin, se trata de organizar el código con responsabilidades bien definidas.

Un cuidado a considerar cuando definimos una capa es el sinkhole anti-pattern que ocurre cuando pasan el request a la siguiente capa solamente por cumplir con la arquitectura, pero la capa no hace nada. Cuando hablamos de arquitectura, también hablamos de compensaciones y ese anti patrón podríamos aceptarlo cuando eso pasa hasta el 20% de los casos (una recomendación).

Sobre su popularidad

Puede que no sea una arquitectura muy querida y parezcamos débiles como arquitectos y programadores cuando estemos utilizando una. Pero en realidad es el estilo de arquitectura más utilizado por su simplicidad y bajo costo. En general, no tendremos que construir aplicaciones que compitan con la Nasa en cuanto a tecnologías a usar y tampoco su complejidad.

La arquitectura por capas se usa muchísimo para aplicaciones web y móviles. También es una buena opción cuando todavía no hemos definido alguna, pero ya tenemos que comenzar el proyecto. También tienen mala reputación cuando encontramos proyectos sin arquitectura definida que se les llama capas sin respetar ni siquiera sus principios.

El estilo de arquitectura por capas siempre tiene que estar entre las opciones de las arquitecturas a elegir. Cuando comienzas un proyecto puedes usarla como arquitectura por defecto mientras no se defina alguna. Recuerda siempre que una arquitectura en capas también tiene reglas a respetar.

Ventajas:

• Clara separación de responsabilidades en capas aisladas ayudando también en la mantención.
• Rápido comienzo de proyecto por su simplicidad.
• Bajo costo.

Desventajas:

• Difícil de deployar porque fuerza a deployar todas las capas para cualquier cambio (aunque se puedan diseñar otras opciones).
• Bajo performance por la dificultades para escalar
• Fácil de testear? si y no porque el proyecto puede crecer mucho como para levantar toda la aplicación cuando es monolítica, además de testear toda la app cuando hay pequeñas modificaciones.