¿Por qué deberías aprender y utilizar Clean Architecture?
Clean Architecture diseña sistemas escalables, mantenibles y fáciles de probar y aquí te lo demuestro con ejemplos reales 🐿️🫡

Hey estimados devs, en este artículo quiero explicar algo que por ahí, no he visto mucho, al menos en artículos, y quiero también que al finalizar este artículo tengas muy claro el porqué de la existencia de la arquitectura limpia, y en qué escenarios es recomendado.

Ya que lo que sí he visto, y mucho, es contenido diciendo el porqué no deberías usarla, y aunque creo fielmente que no existe una arquitectura "bala de plata" es decir que sea perfecta, ni tampoco existe la arquitectura OSFA (one size fits all) es decir que le quede bien a absolutamente todos los proyectos; sí creo que Clean Architecture es una arquitectura muy útil para muchísimos escenarios hoy en día.

Contexto

En el mundo del desarrollo de software, hay un sinfín de arquitecturas y patrones disponibles, pero una que destaca por su claridad y enfoque estructurado es Clean Architecture. Diseñada por Robert C. Martin. Esta arquitectura tiene como objetivo principal hacer que los sistemas sean fáciles de mantener, escalar y entender.

En este artículo, te explicaré por qué deberías aprender y utilizar Clean Architecture, con ejemplos prácticos que te ayudarán a comprender su importancia. Ejemplos realistas, ejemplos del mercado y la industria allá afuera 🎖️😉.

Separación de Responsabilidades

Clean Architecture está diseñada para dividir tu aplicación en capas claras, donde cada una tiene un propósito específico. Estas capas son:

  • Dominio: Contiene las reglas de negocio y las entidades principales del sistema. Es independiente de cualquier tecnología externa.
  • Aplicación: Define los casos de uso y la lógica específica para cada funcionalidad de tu sistema.
  • Infraestructura: Contiene las implementaciones técnicas como bases de datos, APIs externas, y otras dependencias.
  • Presentación: Maneja la interacción con los usuarios, ya sea a través de una interfaz gráfica, API REST, GraphQL, SPA o cualquier otro medio.

Ejemplo práctico:

Si estás desarrollando una tienda en línea:

  • En la capa de Dominio, tendrás una clase Product con propiedades como Name, Price y Stock, así como las reglas para validar el precio o calcular el descuento.
  • En la capa de Aplicación, puedes crear un caso de uso CheckOutOrder que valide el stock y procese el pago.
  • En la capa de Infraestructura, tendrías la implementación del repositorio ProductRepository para conectar con la base de datos.
  • En la capa de Presentación, tendrías un OrderController que reciba las solicitudes HTTP y las pase al caso de uso correspondiente.

Independencia de frameworks y tecnologías

Una de las mayores ventajas de Clean Architecture es que tu sistema no está acoplado a ninguna tecnología en particular. Esto significa que puedes cambiar el framework de tu aplicación, el proveedor de la base de datos o incluso la interfaz de usuario sin afectar tu lógica de negocio.

Ejemplo práctico:

En el ejemplo de la tienda en línea, supongamos que estás utilizando Entity Framework como ORM en la capa de Infraestructura para gestionar el acceso a la base de datos. Si decides cambiar a Dapper, solo necesitarías modificar el código dentro del ProductRepository. Esto no afecta las capas de Dominio ni Aplicación, ya que el caso de uso CheckOutOrder sigue funcionando sin cambios.

Fácil de probar

Gracias a la separación de responsabilidades, las pruebas unitarias son más sencillas de implementar. Puedes probar la lógica de negocio sin preocuparte por dependencias externas como bases de datos o APIs.

Ejemplo práctico:

En el caso de uso CheckOutOrder, puedes escribir pruebas unitarias que simulen escenarios como:

  • Intentar realizar un pedido con stock insuficiente.
  • Validar que se aplique correctamente un descuento si el producto está en promoción.
  • Verificar que se reduce la cantidad de stock después de un pedido exitoso.

Para estas pruebas, puedes usar un repositorio simulado (mock) en lugar del ProductRepository real.

Mantenibilidad y escalabilidad

Al tener una estructura clara y bien definida, agregar nuevas funcionalidades o hacer cambios es mucho más sencillo. Cada cambio estará limitado a una capa específica, lo que reduce el riesgo de introducir errores en otras partes del sistema.

Ejemplo práctico:

Si necesitas agregar un módulo de "historial de pedidos" en tu sistema de tienda en línea, simplemente crearás:

  • Una nueva clase en la capa de Dominio llamada OrderHistory para representar el historial de pedidos.
  • Un caso de uso en la capa de Aplicación llamado GetOrderHistory que permita consultar dicho historial.
  • Una implementación en la capa de Infraestructura para recuperar los datos desde la base de datos en un nuevo repositorio OrderHistoryRepository.
  • Un endpoint en la capa de Presentación, como OrderHistoryController, que reciba solicitudes para obtener el historial de pedidos y llame al caso de uso correspondiente.

    Estandarización

    Al seguir Clean Architecture, tu equipo tendrá una guía clara sobre cómo estructurar el código. Esto reduce la curva de aprendizaje para nuevos desarrolladores y facilita el trabajo en equipo.

    Ejemplo práctico:

    Si un desarrollador nuevo se une al equipo que trabaja en la tienda en línea, podría identificar rápidamente:

    • Que las reglas de negocio, como los descuentos, están en la capa de Dominio.
    • Que los casos de uso, como CheckOutOrder, están en la capa de Aplicación.
    • Que las implementaciones técnicas, como el acceso a la base de datos mediante ProductRepository, están en la capa de Infraestructura.
    • Que los controladores, como OrderController, están en la capa de Presentación.

    Esto permite que los nuevos desarrolladores comiencen a contribuir al proyecto más rápidamente.

    Conclusiones

    Clean Architecture no es un conjunto de reglas que hacen tediosa la labor de programar, es una arquitectura de software que utiliza buena parte de la filosofía DDD (Domain driven design) que te permite crear sistemas robustos, flexibles y fáciles de mantener. Si bien puede requerir un esfuerzo adicional al principio, los beneficios a largo plazo superan con creces la inversión inicial.

    Espero haberte ayudado ahora a entender qué es clean architecture, y el porqué deberías usarlo.

    Ahora que ya sabes esto, sal en familia o amigos y diviértete. Foto de Natalya Zaritskaya en Unsplash

    Si esta entrada te ha gustado estimado dev, compártela! 🫡🐿️

    Créditos de imagen de portada: Foto de ThisisEngineering en Unsplash

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *