¿Recordás la primera vez que escribiste código? Tal vez fue un hello world o algún otro primer programita. Era genial, ver cómo un par de líneas de código empezaban a funcionar... Par de líneas a menos que haya sido en Java.
Si están leyendo esto, puede que haya pasado mucho tiempo desde que escribieron ese programita. El mundo ha cambiado, ya no es como antes. Nos hemos metido a proyectos y experiencias mucho más complejas que nuestro primer contacto con el vasto mundo del desarrollo de software.
.jpg)
De la complejidad se derivan los retos.
No sé si alguien dijo eso pero se escuchaba genial.
Uno de los más grandes que han aparecido ha sido la escalabilidad, que en breves palabras se define como la capacidad de un sistema de crecer en carga de trabajo sin morir en el intento.
A su vez, cuando un proyecto crece, debe ser confiable en el sentido que podemos estar tranquilos de que no va a morir o por lo menos no fácilmente. Para asegurar confiabilidad, hay que mantener un código con sus pruebas de manera correcta. En resumen, el código debe estar probado correctamente para garantizar que sirva.
Por último, está una característica que muchos usuarios no perciben ya que no ven el código base, pero esto habla bien de cualquier sistema que lo posea. Esto se llama desacoplamiento, que está muy relacionado a la reutilización de código e independencia de cada parte del software. En este caso, desacoplamos para que nuestro código sea modular y podamos jugar con él como si fueran piezas de LEGO modificables en tamaño, forma o color siempre y cuando siga calzando. Así tenemos piezas reutilizables y somos más productivos con un código más ordenado.
Podría pasar hablando mucho de cómo podemos escribir mejor código y buenas prácticas, pero mejor explicamos Clean.
Clean es una arquitectura sugerida por Robert C. Martin, Uncle Bob para los amigos. Pretende cumplir con todas las características que mencioné previamente y tiene una... llamémosle regla de oro.
Para ahorrarme explicaciones complejas, voy a mostrarles un gráfico. No lo sobre analicen, sólo quiero que piensen en las formas que se presentan:
Ignoren las palabras y notemos que sólo son círculos conteniendo a otros más pequeños. Esa es la representación gráfica de la regla de la dependencia, que parafraseada sería algo como:
Las dependencias van de afuera hacia adentro. Por esto, las dependencias no saben nada de los componentes que dependen de ellas.
¿Aún no me explico? Usemos las palabras que salen ahí.
El círculo que contiene a todo podemos ver que tiene el UI, usemos esta en el ejemplo. Según nuestra regla, el UI depende de los Controllers pero un Controller no sabe qué hay en el UI. Así con los demás círculos y los que los contienen.
Una vez más y de otra manera: El círculo pequeño es usado en el círculo grande y NO viceversa.
Espero hayas entendido porque de aquí en adelante voy a asumir que lo hiciste. Sino, hay más información en el Clean Coder Blog del tío Bob.
⚠️ Dado los conceptos más básicos de este enorme tema, quiero aclarar que voy a enfocar los siguientes volúmenes de esta serie de artículos en el desarrollo de las apps en Flutter con Clean, ya que a eso me dedico.
Específicamente para Flutter, Clean tiene una implementación un poco distinta por cómo funciona el framework en la integración de lógica e interfaz gráfica. No podemos desacoplar tanto en ese caso ya que están demasiado relacionadas, pero podemos extraer una buena parte en dos capas:
- Domain/dominio: extrae los contratos en el sistema (interfaces, o clases abstractas en Dart).
- Data/datos: implementa los contratos y obtiene los datos que ocupa el sistema.
Más adelante vamos a profundizar en los componentes de estas capas.
Hasta este punto ya explicamos bastante de la base que se necesita para los siguientes artículos, pero quería hacer unas observaciones finales y concluir.
Cada una de las capas o los círculos que tiene Clean pueden funcionar independientemente de sus dependencias externas, o los círculos que los contienen.
Te pongo un ejemplo práctico del por qué es de esa manera.
Digamos que estamos haciendo un proyecto que inicialmente tiene un API REST para funcionar y hacemos todos los modelos de nuestra aplicación muy ligados al formato JSON. Todos vivían en armonía, pero todo cambió cuando por un requerimiento se nos pidió cambiar a un API con GraphQL.
¿Les suena familiar? Sí, pasa en los mejores equipos. Y si no tenemos una buena arquitectura probablemente nos toque hacer esa migración desde cero.
La ventaja de una buena arquitectura es que nuestras entidades nos permiten implementar modelos con propiedades propias basadas en la tecnología que tengan que implementar. Para que nuestros modelos JSON tengan las mismas propiedades que los GraphQL y sólo varíen en implementación.
Ups, aún no hemos hablado de entidades, lo siento. Si alguna cosa que dije no te hizo sentido y te dejó confundido/a, pues calma, ya vienen los siguientes volúmenes para que comprendas mejor.
Para mientras, concluyamos este artículo.
Intenté hacer una versión un poco más amistosa para principiantes del artículo original sobre Clean Architecture en Clean Coder Blog (ya puse el enlace antes, pero lo pongo aquí otra vez).
Así que como en esa entrada, voy a recalcar que implementar esta arquitectura limpia no significa seguir el gráfico que vieron antes. Si buscan más del tema, van a encontrar muchos gráficos más que mencionan otros aspectos y ese es el punto, esto varía por proyecto.
Lo que tienen que tomar en cuenta para realmente implementar la arquitectura es siempre usar la regla de la dependencia. Con ese principio, ya seguimos el desacoplamiento a como realmente se debe. Ya el nivel de abstracción que querás implementar en tu código es decisión tuya. A medida que se abstraiga más, pueden surgir incluso más capas.
Termino diciendo que seguir esta regla es muy simple así que espero que lo hagan e igual vamos a tener ejemplos y más consejos en los siguientes artículos (ya lo he dicho mucho pero para que sigan atentos) para que no sufran haciendo y-más importante- manteniendo buen software.
Si aprendiste algo nuevo y te fue de utilidad, podés compartir este artículo para ayudar a otro/a desarrollador(a) a seguir mejorando su productividad y calidad al escribir aplicaciones con Flutter.
Además, si te gustó este contenido, podés encontrar aún más y seguir en contacto conmigo en mis redes sociales: