Arquitecturas, Software
"Explorando las Arquitecturas Limpias"
Desde hace mucho tiempo existen diferentes arquitecturas a la hora de realizar software. Algunas son cómodas de implementar para proyectos pequeños y de corta duración. Sin embargo, otras nos aportan mantenibilidad en proyectos grandes y de larga duración.
Las arquitecturas tienen como objetivo mejorar la forma en la que trabajamos con el software para que sean mantenibles en el tiempo minimizando el coste. Pero entonces, ¿qué son las arquitecturas limpias? Se definen como una serie de principios de diseño de software que se pueden aplicar a cualquier tecnología.
Arquitectura de capas
Actualmente una de las arquitecturas más conocida y utilizada es la arquitectura de capas que se suele dividir en tres partes bien diferenciadas:
• Controlador: capa que hace las funciones de punto de acceso a nuestra lógica, normalmente en un API es mediante http.
• Servicios: capa donde se sitúa nuestra lógica de negocio y procesos.
• Persistencia: capa que realiza el guardado de los datos y que normalmente se vincula mucho a los servicios.
Estas arquitecturas al principio de la vida útil de un proyecto son mantenibles, limpias y evolucionan rápidamente. Funcionan muy bien cuando el proyecto es pequeño, pero comienzan a ser difíciles de manejar cuando el proyecto aumenta de tamaño. Esta evolución puede llevar incluso a que no estén abiertas a cambios o sean difícilmente testeables porque rápidamente se entremezclan las capas por lo que conviene estudiar bien el proyecto y saber cuándo utilizarlas.
Arquitectura limpia
Existe otro tipo de arquitecturas basadas en unos principios de diseño de software que nos ayudan a mantener sencillas las partes del proyecto, están abiertas al cambio y pueden ser fácilmente testeables. Son conocidas como las arquitecturas limpias. Se pueden aplicar a cualquier tecnología y ayudan a que se desacoplen las partes del software que evolucionan a velocidades diferentes.
Es importante hacer hincapié en la flexibilidad y adaptabilidad que aportan a los sistemas software porque hay que considerar los sistemas como algo vivo que evoluciona constantemente. Una arquitectura limpia se basa, entre otros principios de diseño, en los denominados principios S.O.L.I.D. para mantener todos sus objetivos alineados y tener una estructura que sea fácilmente entendible y testeable. Aplicar los principios SOLID a cualquier proyecto te va a llevar de una u otra forma a que termines utilizando una arquitectura limpia por lo que la implementación puede ser diferente de un proyecto a otro. A continuación, vamos a conocer estos principios un poco más.
Principios Solid
S (SRP) Single responsability Principle: indica que una clase/función sólo debe tener un motivo para cambiar.
O (OCP) Open/Close Principle: abierto a extensión, pero cerrado a modificación.
L (LSP) Liskov Subsitution Principle: : un objeto debe poder ser sustituido por subtipos del mismo sin alterar la clase base.
I (ISP) Interface Segregation Principle: varias interfaces específicas son mejor que una de propósito general.
D (DIP) Dependency Inversion Principle: nos ayuda a que el negocio de la aplicación no dependa de la infraestructura (bbdd, integraciones, etc.)
Arquitectura hexagonal
Un ejemplo de arquitectura limpia es la arquitectura hexagonal, también conocida como arquitectura de puertos y adaptadores, pero hay otras reseñables como la onion architecture. La arquitectura hexagonal separa muy bien las responsabilidades, está abierta a la extensión y es fácilmente testeable. Tiene bien diferenciado el dominio (o modelo) de las reglas de negocio y de la infraestructura. Con este tipo de arquitecturas conseguimos bajar el coste en proyectos de larga duración por estar abiertos a cambios.
Se llama de puertos y adaptadores porque son los pilares para la implementación y unión de las capas externas con nuestro negocio. Usamos los puertos para definir el contrato entre negocio e infraestructura (frameworks, bbdd, etc) y los adaptadores son los encargados de implementar esos puertos o contratos adaptándolos a la especificación externa (por ejemplo, podríamos tener implementados un adaptador para DB2 y otro para MongoDB pero los dos cumplirían con la especificación del contrato).
¿Cómo podemos ayudarte en ARENA?
Introducir este tipo de arquitecturas siempre es beneficioso para que el proyecto pueda evolucionar sin miedo a que se cambie una funcionalidad ya desarrollada. En ARENA estamos implementando la arquitectura hexagonal para nuestros proyectos como base para dar solidez y calidad de código. De esta forma conseguimos dar una mayor robustez y permisividad a cambios en nuestros proyectos y eso se traduce en mayor confianza por parte de nuestros clientes.
La princiapl ventaja de implementar este tipo de arquitecturas es hacer verticales que se adaptan al negocio de cada cliente, obteniendo partes que puedan ser reutilizables, aportando menor coste al proyecto.
Como ves esta tipología de arquitecturas tiene muchas ventajas, pero no siempre tienen que ser la opción elegida. Es importante valorar el proyecto, conocer su alcance y tener muy claro nuestro objetivo para así implementar una arquitectura u otra.Es por ello que en ARENA utilizamos una metodología propia que siempre nos aporta un gran resultado: escuchar, entender, proponer y ejecutar.
