En este artículo, explicaremos detalladamente los principios fundamentales de la Arquitectura Limpia y la Regla de Dependencia, esenciales al diseñar cualquier arquitectura de software para nuestros proyectos. Descubriremos cómo estas prácticas fomentan la modularidad, mantenibilidad y flexibilidad en el desarrollo de aplicaciones. Al comprender la importancia de una arquitectura sólida y la gestión adecuada de dependencias, estaremos mejor equipados para crear sistemas robustos y adaptables. Este conocimiento no solo mejora la calidad del software, sino que también establece bases sólidas para futuras iteraciones y expansiones.
A través de la lectura de este artículo, nos adentraremos en la comprensión profunda de la Arquitectura Saneada, evaluaremos críticamente sus Ventajas y Desafíos, y nos embarcamos en la planificación y estructuración de nuestra aplicación de Comercio Electrónico, abrazando completamente los fundamentos de la Arquitectura Saneada.
Diseño
A lo largo de las décadas de evolución en el ámbito del desarrollo de software, se han gestado diversos enfoques y patrones, cada uno portando sus propias virtudes y retos intrínsecos.
Nos sumergimos en la reflexión sobre cómo organizar de manera más eficiente estas capas mediante Clean Architecture, asegurando así un aislamiento efectivo.
¿Por qué estamos aprendiendo Arquitectura Limpia?
En un análisis crítico de la arquitectura actual debemos abordar la pregunta: ¿Qué hay de malo en esta arquitectura actual? Posteriormente, explicaremos estrategias y soluciones para la mejora, respondiendo a la segunda interrogante: ¿Cómo podemos mejorar el diseño actual? Este proceso de evaluación y optimización nos conducirá hacia una arquitectura más eficiente y adaptable. Acompáñanos en este viaje de reflexión y transformación, donde identificamos desafíos y trazaremos el camino hacia una mejora continua en el diseño de nuestro sistema.
Con estas preguntas, sembramos la semilla de un desafío relacionado con la arquitectura en capas y nos embarcamos en la travesía de su resolución a lo largo de este artículo. La cuestión cardinal se manifiesta en el intenso entrelazamiento entre capas que dependen entre sí.
Como solución, hemos optado por elegir el estudio de la Arquitectura Limpia, aplicando el principio de la Regla de Dependencia. La meta subyacente es incorporar características de flexibilidad y capacidad de prueba en nuestra arquitectura existente.
Esto implica que, con la implementación de la Arquitectura Limpia, ampliaremos; Flexibilidad y capacidad de prueba. Como se mencionó anteriormente, mediante la arquitectura en capas y el SoC, logramos una organización eficiente y la mantenibilidad del código. Por lo tanto, con Clean Architecture, nos proponemos proporcionar flexibilidad y capacidad de prueba. A propósito, aunque aún nos mantenemos en los estilos de arquitectura monolítica, podríamos concebir que estamos explorando sub arquitecturas de la arquitectura monolítica, tales como capas – limpias – hexagonales, y así sucesivamente.
¿Qué es la arquitectura limpia?
La arquitectura limpia figura como el patrón arquitectónico más predominante en la ingeniería de software. Se configura como una táctica de diseño de software que segmenta los elementos de un diseño en niveles circulares. La concepción de la arquitectura limpia proviene de Robert C. Martin y ha sido ampliamente difundida a través de su blog, Uncle Bob.
Se presenta una arquitectura limpia destinada a estructurar el código, donde la lógica empresarial se encapsula en círculos internos sin dependencias, y los códigos de implementación se separan en los círculos externos. Esto implica mantener la lógica empresarial principal y el dominio de la aplicación en el epicentro de la estructura de la solución. Por lo tanto, desarrollamos lógicas de negocio de aplicaciones centrales y objetos de dominio en el núcleo de nuestra arquitectura, preservándolos independientes de las capas de presentación y acceso a datos.
Esto otorgará flexibilidad frente a cambios en la tecnología y las interfaces. Además, la aplicación principal se mantiene constante e independiente de las capas de presentación, las infraestructuras y las bases de datos. El propósito fundamental de la arquitectura limpia es forjar sistemas de software que no solo sean fáciles de mantener, probar y evolucionar con el tiempo, sino que también exhiban robustez, flexibilidad y capacidad para adaptarse a los requisitos cambiantes.
En su esencia, la arquitectura depurada se fragmenta en dos elementos cruciales: las políticas y los detalles. Las políticas abrazan las reglas y procedimientos empresariales, mientras que los detalles encapsulan el código de implementación encargado de llevar a cabo dichas políticas.
Dentro de la arquitectura depurada, no se requiere la elección inicial de la base de datos o el marco; en cambio, se centra en las políticas y lógicas empresariales derivadas de los requisitos del proyecto. Posteriormente, se implementan estas políticas en capas externas mediante la aplicación de diversas pilas tecnológicas, bibliotecas y marcos. La representación gráfica de la Arquitectura Limpia está disponible para su visualización:
Las capas internas encapsulan las políticas empresariales sin depender de bibliotecas externas, lo que posibilita la adopción de diversos marcos y herramientas sin imponer limitaciones en caso de cambio tecnológico. Por lo tanto, las capas externas albergan una implementación concreta con dependencia de las capas internas y de herramientas de terceros.
La regla de dependencia
En esta etapa, resulta crucial internalizar el principio fundamental de la Arquitectura Limpia, conocido como la Regla de Dependencia. Según esta regla, las dependencias en un código fuente deben dirigirse exclusivamente hacia el interior, lo que implica que las dependencias de código sólo pueden fluir desde niveles externos hacia niveles internos.
El código contenido en las capas internas no puede tener conocimiento de las funciones en las capas externas. La capa interna no debe contener información alguna sobre los elementos de una capa exterior. Las clases, funciones, variables, formato de datos o cualquier entidad declarada en una capa externa no deben ser referenciadas en el código de una capa interna. Además, se recomienda mantener los formatos de datos separados entre niveles.
Capas
En el corazón de la Arquitectura Limpia reside la concepción de dividir el código en estratos, cada uno con responsabilidades y propósitos específicos. Estos estratos engloban:
Capa dominio: En este estrato, se encapsula la lógica empresarial y las reglas fundamentales de la aplicación. Debe mantener su autonomía respecto a cualquier marco o tecnología específica, definiendo los dominios esenciales y las reglas empresariales del sistema.
Capa de casos de uso: Aquí residen los casos de uso específicos de la aplicación, representando las acciones realizables por el sistema. Este estrato debe depender del estrato de dominio, pero no debe tener dependencia de ninguna tecnología o marco externo.
Capa de interfaz: Este estrato engloba las interfaces de la aplicación, como la interfaz de usuario o la API web. Debe depender del estrato de casos de uso, pero no debe tener dependencia del estrato de dominio ni de ninguna tecnología externa.
Capa de infraestructura: En este estrato se encuentran los detalles de implementación de la aplicación, como la base de datos o las API externas. Debe tener dependencia de todos los demás estratos, pero no debe depender de ningún marco o tecnología específica. Este constituye el estrato más externo en esta arquitectura limpia, sujeto a cambios frecuentes según las tecnologías y actualizaciones, como la base de datos y los marcos de front-end web.
Beneficios
La arquitectura depurada facilita el diseño de aplicaciones con conexiones de dependencia extremadamente baja e independientes de los detalles técnicos de implementación, como bases de datos y frameworks. Esto hace que la aplicación sea fácil de mantener y flexible para cambios. Los beneficios que nos concede la arquitectura depurada:
- Libre de ataduras con la base de datos y los marcos, el software no está comprometido con un ORM o sistema de gestión de bases de datos. Los cambios pueden llevarse a cabo con facilidad.
- Independencia de la interfaz de usuario La interfaz de usuario puede ser alterada con facilidad, sin afectar el resto del sistema y las reglas de negocio.
- Es naturalmente comprobable. Puedes realizar pruebas de las reglas de negocio sin tener en cuenta la interfaz de usuario, la base de datos, los servidores simulados, y demás.
- Independencia de cualquier entidad externa De hecho, las reglas de negocio no tienen conocimiento alguno sobre el entorno externo.
¿Cuándo utilizar la Arquitectura Limpia?
La arquitectura limpia demuestra ser excepcionalmente valiosa en situaciones en las que se aspira a crear un sistema altamente flexible, comprobable y adaptable a lo largo del tiempo. Estos son algunos escenarios específicos en los que la arquitectura limpia puede ser una opción beneficiosa:
Proyectos de software grandes o complejos: En el contexto de trabajar en un proyecto de software extenso o complejo, la administración del código y la garantía de su mantenibilidad y verificabilidad a lo largo del tiempo pueden plantear desafíos. La arquitectura depurada presenta un enfoque estructurado para organizar el código, contribuyendo así a mitigar estos problemas.
Aplicaciones que requieren actualizaciones o cambios frecuentes: Cuando se está construyendo una aplicación que se espera que experimente actualizaciones o cambios con regularidad, la Arquitectura Limpia puede facilitar la implementación de estas modificaciones sin generar problemas en otras áreas del sistema.
Aplicaciones que deben ser altamente comprobables: La Arquitectura Limpia puede ser un apoyo para desarrollar una aplicación altamente verificable, reduciendo el riesgo de errores y simplificando el diagnóstico y la corrección de los problemas que puedan surgir.
Contras de la arquitectura limpia
Aunque la arquitectura limpia aporta numerosos beneficios al desarrollo de software, no se puede pasar por alto algunos posibles inconvenientes. Aquí se enumeran algunos de los más comunes:
Configuración inicial y curva de aprendizaje: La adopción de la arquitectura limpia podría implicar una fase de configuración más prolongada y exigir que los desarrolladores novatos en este enfoque superen una curva de aprendizaje. Esto podría generar cierta carga adicional al proyecto en sus etapas iniciales.
Sobreingeniería: Es viable excederse en la planificación de un sistema de software al intentar aplicar de manera excesivamente rigurosa los principios de la Arquitectura Limpia. Esto podría generar un código excesivamente complejo, tornándose difícil de comprender y mantener.
Complejidad añadida: La arquitectura limpia puede añadir algo de complejidad adicional a un proyecto, especialmente cuando se trata de gestionar las interacciones entre las diferentes capas del sistema.
Aplicación de comercio electrónico
En caso de diseñar una aplicación de comercio electrónico aplicando la arquitectura limpia, podrás apreciar la siguiente representación gráfica:
Existe un extenso servidor de aplicaciones monolítico, pero la aplicación incorpora capas de arquitectura limpia, incluyendo dominio, aplicación, infraestructura e interfaz de usuario web. Además, cuenta con una extensa base de datos relacional.
Si optamos por diseñar una aplicación de comercio electrónico aplicando la arquitectura de microservicios, podrás apreciar la siguiente representación gráfica:
El microservicio asociado al producto puede optar por la base de datos de documentos NoSQL, en tanto que el microservicio vinculado al carro de compras tiene la opción de utilizar la base de datos de pares clave-valor NoSQL. En cuanto al microservicio Order, su elección recae en la base de datos relacional, ajustándose así a los requisitos particulares de almacenamiento de datos.
Conclusiones
En conclusión, la adopción de Clean Architecture emerge como un paradigma transformador en el desarrollo de software, priorizando la separación de preocupaciones y la mantenibilidad. La estructura jerárquica, con capas bien definidas, propicia una arquitectura flexible y testeable. La independencia de frameworks externos y la orientación hacia casos de uso, no solo mejora la legibilidad del código, sino que también facilita futuras expansiones y modificaciones. Sin embargo, la implementación de Clean Architecture demanda un cambio cultural y un compromiso firme con los principios establecidos. Los beneficios, en términos de escalabilidad y evolución del software, compensan estos desafíos, creando un entorno propicio para el desarrollo ágil y sostenible de aplicaciones robustas y de alta calidad. En última instancia, Clean Architecture se erige como un enfoque valioso para construir sistemas resilientes y adaptables en el cambiante panorama del desarrollo de software.
