En el post anterior vimos qué era la arquitectura de software y para qué nos servía. En este nuevo post vamos a ver más en detalle la arquitectura de capas. 

Se destaca por ser fácil de implementar en el comienzo del proyecto y fácil de entender para principiantes en el desarrollo de software.  

Lo que propone la arquitectura de capas es pensar nuestro sistema en capas y cada capa debe exponer en forma clara las operaciones que puede realizar. Estas operaciones se deben exponer mediante un api que nos digan qué servicio me ofrece esa capa y cuál será su retorno sin importar como este implementado. Por ejemplo, una URL es un api que me dice que datos necesito ingresar y que me devolverá o también puede ser una clase con metodos públicos, etc. 

Pueden existir n capas, pero cada una debe tener una responsabilidad única. Una separación muy utilizada es la de tres capas “presentación”, “lógica de negocio” y “acceso a datos”. 

Muchos en este punto se preguntarán ¿Qué es una capa?

Una capa es un conjunto de “cosas” que tienen cierta responsabilidad. Por ejemplo, una capa puede ser un conjunto de clases, agrupadas en un paquete, dentro de nuestro programa que representan cierta responsabilidad o también puede ser un jar que se comunica con otros y cada jar representa una capa o pueden ser un sistema y cada sistema es en sí una capa. Cuando nos referimos a capas es una abstracción de responsabilidades. 

Además, la arquitectura establece reglas de cómo se deben comunicar las capas. 

Primera regla 

Cada capa debe tener una responsabilidad única. Es decir que las capas deben estar perfectamente delimitadas de que se ocupa cada una de ellas, por ejemplo, podemos tener una capa de “presentación” que será la encargada de atender los eventos del cliente y encargada de representar la información para el mismo. Por otro lado, podemos tener la capa de “acceso a datos” que será la encargada de guardar y acceder a los datos. 

Segunda regla 

Las capas deben respetar una estructura jerárquica estricta. Quiere decir que cada capa pude comunicarse solo con la que está debajo suyo, pero NO al revés. Por ejemplo, una clase ubicada en la capa de presentación puede llamar a un método ubicado en la capa de acceso a datos, pero nunca la capa de acceso a datos puede llamar a un método de la capa de presentación. Y cuando nos referimos a la próxima más baja significa que no se puede saltar capas. Veamos un ejemplo gráfico. 

Para este ejemplo utilizaremos la separación de tres capas “presentación”, “lógica de negocio” y “acceso a datos”. Esto es lo que se debería hacer y lo que no se debería hacer. 

Ventajas 

Entre sus ventajas se encuentran las siguientes: 

• Es fácil testear cada capa por separado debido a la separación clara de responsabilidades que existe entre ellas. 
• Al momento de hacer un cambio, si se implementó bien la separación de responsabilidad, este cambio solo debe impactar a la capa responsable y no a todas. Esto se conoce como desacople. 

Desventajas 

• Si se implementaron demasiadas capas el rendimiento de la aplicación puede verse afectado  
• Ciertas operaciones al ser modificadas pueden afectar a todas las capas, haciendo visible que no existe un 100% de desacople entre estas. 

Arquitectura de tres capas 

La arquitectura de tres capas en particular es muy utilizada ya que propone dividir las capas en 3 específicas que son frecuentes en aplicaciones empresariales web. Como veníamos mencionando en los ejemplos las capas que propone son las siguientes. 

Presentación: Atiende los eventos del cliente y representa los datos para el mismo. Teniendo en cuenta que el cliente puede ser un humano u otro sistema, esta capa será encargada en caso del humano de atender los clics (u otros eventos) en un HTML y de renderizar la información de manera visual. En caso de que sea otro sistema puede atender peticiones rest y devolver información en un formato estructurado (json, xml, etc) que es más fácil de interpretar por un sistema. 

Lógica de negocio: En esta capa se encuentra todo lo que refiere a las reglas que se encuentran en el negocio, o sea los requerimientos funcionales de nuestro sistema. Por ejemplo, si se tiene un alta de usuario esta capa debe proveer el medio para altaDeUsuario y dentro del método se debe realizar todos los pasos para dar de alta un usuario (enviar mail, validar nombre, etc). 

Acceso a datos: Mediante esta capa podremos obtener o guardar los datos que utilizara nuestra aplicación. Observar que no habla de cómo se realiza la persistencia, si es en base de datos o en archivo o etc, solo habla de acceso a datos. Por ejemplo, esta capa debería proveer un medio para poder guardar el usuario y otro para obtenerlo. 

Beneficio 

Si logramos realizar esta separación de responsabilidades podemos notar como a una capa no le interesa cómo esta implementada la otra. Así yo puedo remplazar las implementaciones de las capas, pero esto no afectaría a las demás. Ejemplo: mi capa de acceso a datos ofrece un método guardarUsuario y por dentro este es guardado en un txt. En el futuro deseo cambiar esta implementación entonces seguiría existiendo el método guardarUsuario pero por dentro este es persistido en una base de datos. Para la capa de lógica de negocio esto no debería importar ya que lo único que desea es que el usuario sea guardado sin importar cómo. 

Esto fue todo sobre arquitectura de capas y en especial de tres capas. Próximamente veremos otras arquitecturas para comparar qué beneficios posee cada una.