Por qué utilizar una Clean Architecture
Se conocen así, porque todas ellas se basan en el mismo principio de diseño de software: la separación de responsabilidades.
Publicado el martes, 22 de noviembre de 2022 a las 08:45
Hoy en día, en el mundo del software, se usan mucho las llamadas Clean Architecture. Se conocen así, porque todas ellas se basan en el mismo principio de diseño de software: la separación de responsabilidades. Una de las más conocidas es la arquitectura hexagonal, pero hay otras tantas. En esta ocasión, te contamos lo que necesitas saber para entender cuándo y por qué utilizar una Clean Architecture.
– Infraestructura: son los elementos externos con los que se comunica la aplicación, tanto de entrada como de salida:
- Puntos de entrada: una API con REST o GraphQL, mensajería con RabbitMQ o mediante línea de comandos, etc.
- Puntos de salida: una base de datos relacional con PostgreSQL, no relacional con MongoDB, o también envío de mensajes con RabbitMQ, etc.
– Application/Use Cases: se trata de la evaluación de reglas de negocio y toma de decisiones. Contienen las reglas que le dan sentido a la aplicación. Los casos de uso dirigen el flujo a las entidades y las orquestan para cumplir con el negocio.
– Domain: responde al modelo de datos de la aplicación, servicios de dominios, interfaces, etc. Las entidades son los modelos definidos que interactúan en el sistema; deben ser lo suficientemente abstractas para ser usadas por múltiples aplicaciones en el negocio.
La arquitectura limpia debe ser capaz de aplicarse a cualquier sistema, sin importar el lenguaje de programación o las librerías que utilice. Las capas deben quedar tan bien separadas que puedan sobrevivir de forma individual, sin necesidad de externos.
Cuanto más pura sea una función, una clase o un módulo (es decir, que no tenga efectos colaterales), más fácil será predecir el resultado que se va a obtener. Cada módulo, tanto de UI, base de datos, conexión a API Rest, etc., se debe poder testar de manera individual.
Uno de los componentes que sufre cambios de forma constante es la interfaz de usuario. La UI debe ser capaz de cambiar sin alterar todo el sistema. Si vamos más allá, esta capa debería vivir tan independiente como para ser desensamblada y sustituida por otra. Por ejemplo, que se pueda cambiar una UI Móvil por una en modo consola.
Como en el punto anterior, esta capa debe ser tan modular como para agregarle múltiples fuentes de datos e, incluso, múltiples fuentes del mismo tipo de datos. Por ejemplo, manejar varias bases de datos como MySQL, PostgreSQL, Redis, etc.
Si en algún punto de tu sistema necesitas de una librería, otro sistema o cualquier elemento por conectar, debería ser fácilmente ensamblado y modularizado. De hecho, para el sistema, esta capa externa debería ser transparente.
Esta tecnología es ideal cuando tienes un proyecto a largo plazo. Si necesitas que perdure en el tiempo, que lo puedas testear con facilidad y alta tolerancia al cambio, que puedas minimizar el impacto de estos cambios, aprovecha los beneficios de esta clase de arquitectura:
Puedes implementarla con cualquier lenguaje de programación, entre los que citamos: Java, .Net, Php, Node.js, etc.
Esto significa que se coloca el foco primario del proyecto en el núcleo y la lógica del dominio.
Esta arquitectura permite realizar cambios importantes en la aplicación, sin grandes impactos:
- Podrías cambiar el framework utilizado en caso de ser necesario, ya que está todo desacoplado.
- Podrías, además, cambiar la base de datos que uses o agregar alguna otra si la necesitas.
Tienes la oportunidad de testear de manera rápida y fácil. Podrías realizar test unitarios de cada una de las capas y test de integración de las diferentes capas entre sí, pudiendo reemplazarlas por objetos temporales que simulen su comportamiento de forma sencilla.
Crearás un producto sólido, de calidad y escalable.
Ahora bien, si quieres realizar un producto mínimo viable (PMV), te recomendamos que evites estos tipos de arquitectura. Tardarás demasiado, y requerirá de un costo y esfuerzo innecesarios. Si ese PMV funciona y necesita de un desarrollo más potente y avanzado, las Clean Architecture seguro podrán ayudarte.
Las Clean Architecture encajan muy bien con el enfoque de Domain-Driven Design (DDD). Pero, ¿qué relación tienen estas arquitecturas limpias con DDD?
Al ser una arquitectura que fomenta que nuestro dominio sea el núcleo de todas las capas, y que no se acople a nada externo, funcionan perfecto juntos. Podríamos decir que DDD se basa en una clean architecture como pilar central en términos de arquitectura.
Ahora que conoces cuándo y por qué utilizar una Clean Architecture, podrás definir si es la mejor opción para tu proyecto. En MyTaskPanel Consulting, contamos con profesionales de calidad que tienen experiencia en el tema y podrán ser el apoyo tecnológico que necesitas. Consúltanos sin compromiso aquí.
22/11/2022 08:45 | mario.rosal