La arquitectura hexagonal sigue aumentando su popularidad, debido a la gran oportunidad de escalabilidad en un proyecto.

La arquitectura hexagonal es una practica deseada en proyectos que van a creccer.

¿Qué es un proyecto GRANDE?

Un proyecto grande no significa que va tener mucho tráfico o usuarios. En este contexto el tráfico y cantidad de usuarios no tiene una conexión directa.

Lo que define a un proyecto como «GRANDE» y «ESCALABLE» es todo aquel proyecto que tendría estas características

• Acceso a Hardware
• Uso de varias API y muchos endpoints
• Autenticación
• Muchas funcionalidades
• Requiere más de 1 programador

Estos detalles clasificarían a una app para usar Arquitectura Hexagonal. A pesar de todo, Clean Code siempre es una buena practica en todos los proyectos que hagas. Pero no en todos tus proyectos necesitas Arquitectura Hexagonal.

¿Cuándo es necesario usar Arquitectura Hexagonal?

Si bien el líder del proyecto elige la arquitectura del proyecto, considera otros factores que hacen sentido a votar por usar Arquitectura Hexagonal o no.

• Cuando la App se proyecta a estar en el mercado muchos años.
• Cuando la App está planeada para personalización.
• Cuando la App usa dependencias de terceros.
• Cuando la App tendrá rotación de persona.

¿Cuándo no es necesario usar Arquitectura Hexagonal?

• Cuando la App tiene un par de funcionalidades y no usa dependencias
• Cuando la App no se basa en un solo archivo.
• Cuando es un MVP (Producto Minimo Viable)
• Etc.

Estructura de carpetas para Arquitectura Hexagonal

Crea un archivo flutterhex.sh y pega este contenido.

Luego agrégalo un alias para facilitar su ejecución: alias flutterhex=»~/flutter_hex.sh»

1. En la carpeta de infraestructura se debe crear un archivo remote_api_client.dart que contendrá la lógica para conectarse y consumir los datos de la API remota. En este archivo se debe utilizar la librería dio para realizar las peticiones HTTP.
2. Crear una clase LoginRepository en la carpeta de domain que será la encargada de manejar la lógica de autenticación del usuario. Esta clase debe depender del RemoteApiClient.
3. Crear un usecase llamado LoginUseCase en la carpeta de application que utilizará el LoginRepository para realizar la autenticación del usuario. Este usecase debe recibir como parámetros las credenciales del usuario y devolver un objeto que indique si el inicio de sesión fue exitoso o no.
4. Crear un BLoC llamado LoginBloc en la carpeta de presentation que maneje el estado de la pantalla de inicio de sesión y utilice el LoginUseCase para realizar la autenticación del usuario.
5. En la página de inicio de sesión (login_page.dart) se debe utilizar el BLoC para manejar el estado de la pantalla y consumir la API remota. La página debe incluir un formulario de inicio de sesión que envíe las credenciales del usuario al BLoC cuando se presione el botón de inicio de sesión.
6. Para mostrar una animación mientras se está realizando la petición HTTP, se puede utilizar una librería como flutter_spinkit que incluye una variedad de animaciones predefinidas. En la página de inicio de sesión se puede mostrar una animación mientras se espera la respuesta de la API remota, y cambiarla por un mensaje de error o redireccionar a la pantalla de inicio si el inicio de sesión fue exitoso.

¿Se usa un gestor de estado para esto?

Definitivamente, Flutter en si mismo no dispone de un gestor de estado debido a su naturaleza. Por lo tanto podemos optar por nuestro gestor favorito.

Por ejemplo BLoC: BLoC se se encargará de manejar el estado de la pantalla y comunicarse con los usecases y los repositorios correspondientes para realizar las operaciones necesarias. La página se debe encargar de mostrar el estado actual de la pantalla y enviar eventos al BLoC cuando el usuario interactúa con la interfaz de usuario. La infraestructura se encarga de manejar la conexión con los datos remotos y locales.