Entendiendo a la arquitectura limpia

Nestor Calderón
6 min readMar 7, 2021

--

La arquitectura limpia y cómo puede beneficiar significativamente sus proyectos de desarrollo de software.

Me pareció importante compartir estas líneas dado a la gran cantidad de información que existe sobre el tema y que a su vez podría enredar a algunos con demasiado tecnicismo, esta lectura es corta y concisa.

Actualmente el mercado es fuerte y agresivo y las compañías necesitan trabajar continuamente en sus productos y servicios digitales para mantenerse relevantes, mantenerse al día con las crecientes demandas de los usuarios y llegar a un público más amplio.

En este contexto, la arquitectura del software juega un papel fundamental. Y una metodología en particular ha ido ganando popularidad en los últimos años: estamos hablando de Arquitectura Limpia .

Adoptar una mentalidad de arquitectura limpia en proyectos grandes y de alto riesgo, como el desarrollo de una nueva aplicación, permite a su equipo crear un producto más rentable que sea fácil de desarrollar, mantener e implementar.

En esta historia, se pretende dar descripción general de qué es la Arquitectura Limpia y cuáles son sus principales características y beneficios.

Entonces, ¿Qué es la arquitectura limpia?

La arquitectura limpia es una filosofía de diseño de software presentada por Robert C. Martin en 2017 en un libro con el mismo nombre . Básicamente se refiere a la organización del código en componentes o módulos separados y cómo estos elementos se relacionan entre sí.

El objetivo principal de Clean Architecture es proporcionar una metodología para desarrollar código que funcione mejor, tenga pocas dependencias y sea fácil de entender y mantener, lo que reduce los costos y maximiza la productividad del programador.

En los últimos años, Clean Architecture se ha vuelto bastante popular y muchos equipos de desarrollo de software la están adoptando en todo el mundo. Una de las principales razones es que ayuda a diseñar aplicaciones con muy bajo acoplamiento y alta cohesión . De esa manera, las aplicaciones se vuelven más probables y flexibles para cambiar a medida que crece el proyecto.

Principales características de una Arquitectura Limpia

La representación más común de Clean Architecture es un diagrama que consta de capas circulares concéntricas, que recuerdan mucho a The Onion Architecture . Las capas internas representan políticas abstractas de alto nivel, mientras que las capas externas son los detalles técnicos de implementación.

La arquitectura de software de una aplicación define dónde el sistema realiza su funcionalidad principal y cómo interactúa con cosas como la base de datos y la interfaz de usuario.

El diagrama de Arquitectura limpia .

En el centro del círculo, tenemos el Dominio o las reglas comerciales. Las reglas comerciales son la razón por la que existe un sistema de software. Son la funcionalidad principal de una aplicación.

Idealmente, el código que representa las reglas de negocio debería ser el corazón del sistema, con preocupaciones menores conectadas a ellas. Las reglas comerciales deben ser el código más independiente e inmutable del sistema.

Cuanto más exterior vayas en el círculo, los elementos se vuelven menos críticos y más propensos a cambiar. En este sentido, la presentación y los datos son menos importantes ya que son implementaciones que eventualmente pueden ser reemplazadas.

La regla de dependencia

La regla principal de Clean Architecture es que las dependencias de código solo pueden provenir de los niveles externos hacia adentro, y las capas internas no deben tener conocimiento de las funciones de las capas externas.

Al asegurarse de que las reglas de negocio y la lógica de dominio estén completamente desprovistas de dependencias externas, logrará lo que se denomina una separación limpia de preocupaciones . Usted crea un límite que garantiza que el núcleo de su aplicación no sepa nada sobre la infraestructura.

Eso significa que la interfaz de usuario y la base de datos dependen de las reglas comerciales, pero las reglas comerciales no dependen de la interfaz de usuario o de la base de datos. No importa si su producto es una interfaz web, una aplicación de escritorio o una aplicación móvil. No importa si los datos se almacenan mediante SQL, NoSQL o la nube. Al Dominio no le importa.

El secreto para construir un producto escalable y fácil de mantener es separar los archivos o clases en componentes que pueden cambiar independientemente de otros módulos. Esto se conoce como arquitectura de complementos .

Diferencia entre flujo de datos y regla de dependencia. Imagen de ProAndroidDev .

Las capas

En el desarrollo de software, la arquitectura limpia clásica se divide en las siguientes capas:

- Entidades : las entidades son el conjunto de reglas comerciales relacionadas que son críticas para el funcionamiento de una aplicación. Son completamente independientes de cualquier otro elemento dentro de la arquitectura. Cuando se emplea una Arquitectura Limpia, las Entidades no saben nada sobre las otras capas.

- Casos de uso : los casos de uso representan las acciones que un usuario puede realizar en la aplicación. Son una descripción de la forma en que debe comportarse un sistema automatizado. Los casos de uso interactúan con las Entidades y dependen de ellas, pero no saben nada sobre las capas externas. Los casos de uso no determinan la apariencia del sistema para el usuario. En cambio, describen las reglas que gobiernan la interacción entre los usuarios y las Entidades.

- Adaptadores de interfaz . Los adaptadores de interfaz proporcionan un puente entre el mundo exterior y los casos de uso y las entidades. Son los traductores entre el Dominio y la Infraestructura. Los modelos, las vistas, los presentadores y las implementaciones de repositorios pertenecen a esta capa.

- Infraestructura. La infraestructura representa a los agentes externos. Esta capa es donde van todos los componentes de E / S: la interfaz de usuario, la base de datos, los marcos y los dispositivos. Es la capa más volátil porque los elementos contenidos aquí tienen más probabilidades de cambiar.

Beneficios de la arquitectura limpia

Adoptar una mentalidad de Arquitectura Limpia en un proyecto de desarrollo de software puede traer grandes beneficios y ventajas en términos de tiempos de trabajo, costos y productividad.

Estos son algunos de los beneficios más importantes de la arquitectura limpia:

- Clean Architecture permite implementar fácilmente un sistema de software con una sola acción, reduciendo costos y tiempos de trabajo.

- La arquitectura limpia permite que los sistemas comuniquen las necesidades operativas de manera eficiente, haciéndolas evidentes para los desarrolladores. Esto simplifica la comprensión del código y, por lo tanto, ayuda en el desarrollo y mantenimiento.

- El mantenimiento suele ser el aspecto más costoso de un proyecto de desarrollo de software. Agregar nuevas funciones y lidiar con errores consume una gran cantidad de recursos. Además de eso, siempre existe el riesgo latente de crear inadvertidamente nuevos problemas mientras se busca en el software para corregir un defecto. Al separar el sistema en componentes y aislar esos componentes a través de interfaces estables, es posible reducir significativamente el riesgo de rotura involuntaria.

- La arquitectura limpia también hace que el código sea mucho más comprobable. Es difícil probar el código cuando hay muchas dependencias. Pero cuando tiene una arquitectura de complementos, eso ya no es un problema.

- Clean Architecture permite que los casos de uso sean más visibles y más fáciles de entender. Las reglas comerciales no están dispersas por todos lados, por lo que la depuración es mucho más fácil.

- Debido a que los casos de uso están desacoplados de la interfaz de usuario o la infraestructura, es fácil hacer cosas como cambiar la base de datos o el marco web o incluso migrar a una plataforma completamente nueva.

Escudriñando mucho mas sobre el tema me encontré un scaffold para esta arquitectura que es una muy buena opción para iniciar un proyecto de software backend.
https://github.com/bancolombia/scaffold-clean-architecture

--

--

Nestor Calderón
Nestor Calderón

No responses yet