Desafiando la norma: llevando Django a la arquitectura hexagonal
En este artículo les queremos compartir la experiencia de Architects y Developers de Flux IT en un proyecto real: una start-up de med tech en EE. UU.
Esta empresa tiene gran velocidad de cambio y releases casi constantes, y para hacer ingeniería, tuvimos que saber elegir la arquitectura correcta para cada estadio de la empresa. A continuación, les contamos los detalles desde la perspectiva de Gabi Moran e Ivan Dackiewicz.
¿Qué opción elegimos?
Para la web API que se encarga de servir la información a la plataforma web del cliente, se optó por utilizar django REST framework. Sin embargo, en lugar de utilizar la arquitectura que este framework recomienda por defecto (Model-View-Controller), se decidió optar por una diferente, siendo esta el patrón conocido como arquitectura hexagonal o ports and adapters.
¿Qué es la arquitectura hexagonal?
La arquitectura hexagonal es un tipo de patrón de arquitectura que separa la capa de dominio de la de aplicación de la de infraestructura.
La capa de dominio es la encargada de conocer la lógica de negocio del cliente, cómo operar con las entidades que lo representan y de definir los contratos con los que esta espera obtener la información con la cual operar. La capa de aplicación es la encargada de llamar a la capa de dominio para resolver las peticiones que le llegan. Por último, la capa de infraestructura conoce cómo se implementan los contratos que la capa de dominio define. Esto se traduce en saber cómo hacer llamadas a las distintas fuentes de datos (como otras web APIs y bases de datos) para devolverle a la capa de dominio la información con la cual operar.
¿Por qué utilizarla en este proyecto?
Dado que el cliente es una start-up, las definiciones y la lógica de negocio son mucho más volátiles que en una empresa ya establecida. Utilizar la arquitectura hexagonal nos permitió que los cambios sean mucho más fáciles de realizar, solo afectando a partes aisladas de la aplicación y sin atentar contra la sostenibilidad de la solución. Por otro lado, la gran cobertura de tests que la web API posee (un 89%), nos dio la confianza suficiente para estar seguros de que la gran mayoría de cambios realizados no iban a romper funcionalidades existentes en otras partes de la aplicación como daño colateral.
¿Qué beneficios trajo para el proyecto el uso de esta arquitectura?
Una de las ventajas de este patrón de arquitectura es que, al tener una capa de dominio totalmente desacoplada, esta no está atada a las tecnologías que se utilizan para conectarlas con el mundo exterior. Esto permitiría inclusive cambiar toda la capa de aplicación y de infraestructura sin que la lógica de negocio se vea afectada.
Además, la arquitectura hexagonal es un patrón de arquitectura que, si se implementa correctamente, tiende a ser mucho más sostenible a largo plazo que otros patrones como Model-View-Controller, dado que la misma arquitectura te fuerza a que las distintas responsabilidades dentro del código estén bien separadas.
Otra de las ventajas de este patrón es la gran testeabilidad. La arquitectura hexagonal permite desglosar las pruebas hasta el punto de aislar las diferentes capas de la aplicación y corroborar su comportamiento tanto de manera aislada como del sistema en su totalidad.
Al principio, cuando se comenzó a desarrollar este servicio para este proyecto, se optó por apostar por el uso de este tipo de arquitectura incluso desconociendo gran parte de la lógica de negocio del cliente. Sin embargo, al ser una arquitectura que está pensada para un software que tiene una alta tasa de cambios, se consideró que su implementación (aunque la configuración inicial es más compleja que la opción por defecto de Django) valdría la pena. Esto fue un gran acierto, dado que a medida que pasaba el tiempo, el código crecía respetando las buenas prácticas estandarizadas por la industria, incluso cuando se trataba de funcionalidades prototipadas. Además, la meta de conseguir un alto porcentaje de cobertura de tests útiles desde el día cero, ha hecho que la mayoría de los bugs se detecten antes incluso de subir el código.
Mirándolo en retrospectiva, y teniendo en cuenta que el cliente ha cambiado muchas de las definiciones de la lógica de negocio a lo largo de la vida del servicio, hoy en día tenemos un servicio que sigue los mejores estándares de calidad de la industria y que gracias a la refactorización continua, no ha sufrido una deterioración a lo largo de sus aproximadamente dos años y medio de vida.
