¿Qué es la arquitectura limpia de Android?

¿Está interesado en una guía de arquitectura limpia de Android?

Has venido al lugar correcto.

Elegir la arquitectura correcta es clave para crear una gran aplicación de software, por eso es tan importante hacerlo bien. Comencemos primero con los desafíos de usar una arquitectura de aplicación de Android.

Desafíos arquitectónicos de aplicaciones de Android

Los proyectos de desarrollo de aplicaciones de Android enfrentan desafíos arquitectónicos como cualquier otro proyecto de desarrollo de software. Estos desafíos surgen de una toma de decisiones incorrecta. Un breve resumen de estos desafíos es el siguiente:

• Favorecer el statu quo: los equipos de proyecto a veces se mantienen en el statu quo a pesar de que la arquitectura no funciona del todo.
• Sobrediseñar la solución: el gran esfuerzo invertido por adelantado en la arquitectura retrasa el proyecto.
• Unirse al carro de los microservicios: Netflix utiliza este patrón con gran eficacia. Eso no significa que todas las aplicaciones tendrán éxito con él. Anteriormente expliqué los pros y los contras del patrón de arquitectura de microservicios en “10 mejores prácticas para construir una arquitectura de microservicios”.
• Elegir un patrón solo porque el equipo lo conoce, aunque no sea adecuado para la aplicación.
• Frecuente obsolescencia de la tecnología.

Lea más sobre estos desafíos en “Desafíos del arquitecto de soluciones y errores comunes”.

¿Por qué surgió la “Arquitectura Limpia”?

Una comprensión de las razones que dieron lugar a la “arquitectura limpia” es útil desde el principio. Así que, aquí vamos:

• La “separación de preocupaciones” siempre ha sido un principio clave para los arquitectos de software. Un ejemplo ayudará a entender esto.
• Consideremos la regla de que la lógica empresarial nunca debe preocuparse por la lógica de la “interfaz de usuario” (UI). Del mismo modo, la lógica de la interfaz de usuario no debe preocuparse por la lógica empresarial.
• Si bien el principio anterior tiene mucho sentido, en la práctica las cosas resultan muy diferentes. El código de lógica empresarial a menudo se ocupa de aspectos de la interfaz de usuario como el color y el tamaño de fuente.
• Los arquitectos de software idearon el patrón de “Arquitectura en capas” para resolver esto. Aquí, los datos ingresan a la capa superior. Fluye a través de las capas intermedias, que tienen sus propias tareas. Los datos finalmente llegan a la capa más interna, que suele ser la base de datos. Obtenga más información sobre la arquitectura en capas en “Arquitectura de proyectos Java para grandes empresas”.
• Supongamos que tenemos una arquitectura en capas, con la interfaz de usuario o la capa de presentación como capa exterior. La capa intermedia es donde residen los objetos, y podemos llamarla “Capa de lógica de negocios” (BLL). La capa interna tiene la base de datos.
• Aquí, los cambios en el BLL pueden dictar cambios en la interfaz de usuario. Si bien eso es aceptable, los pequeños cambios en la apariencia de la interfaz de usuario no deberían causar cambios en el BLL.
• Durante la ejecución, las acciones del usuario activarán cierto procesamiento en el BLL. Como resultado, algunos cambios persistentes en los datos se guardarán en la base de datos.
• Sin embargo, si intenta administrar estas mismas dependencias durante el tiempo de compilación, se encierra con un proveedor de base de datos específico. Esto reduce sus opciones.
• Además, los desarrolladores a menudo pueden mezclar el código de acceso a datos con otro código que realiza cálculos diferentes. Como resultado, la capacidad de prueba de la aplicación se reduce.

Lea más sobre estos desafíos en “Una introducción a la arquitectura limpia”. La comunidad de arquitectos de software necesitaba encontrar soluciones a estos. Introduzca “Arquitectura limpia”.

Una breve historia de la “Arquitectura Limpia”

Ahora hemos resumido los desafíos de los patrones de arquitectura tradicional, de la siguiente manera:

• Acoplamiento difícil de manejar de la interfaz de usuario con otras capas;
• Acoplamiento de la capa de lógica empresarial a factores como el almacenamiento persistente;
• Disminución de la capacidad de prueba.

Robert C. Martin, también conocido como “Tío Bob”, presentó la solución en 2011, y la llamó “Arquitectura Limpia”. Lee su artículo en “arquitectura limpia”. En 2012, amplió la definición de su solución y presentó los diagramas esquemáticos de los componentes de la arquitectura de Android para explicarla.

Leer “La arquitectura limpia” para más información.

¿Qué es la “Arquitectura Limpia”?

Una “arquitectura limpia” es un patrón en el que todas las capas parecen una cebolla. La regla de dependencia es tal que la capa interna no debe preocuparse por la capa externa. Ningún código en una capa interna puede hacer referencia directamente a ningún código de la capa externa.

Por el contrario, una capa exterior puede hablar con la capa interior. En otras palabras, las dependencias apuntan hacia adentro. Leer este hilo de preguntas y respuestas de Quora para más información.

En la práctica, esto significaría lo siguiente:

• La capa más externa, que consta de marcos y controladores, se comunica con la siguiente capa interna.
• Supongamos que esta segunda capa está formada por los adaptadores de interfaz.
• Esta segunda capa luego hablará con la siguiente capa interna. Esta será la capa de reglas de negocio de la aplicación.
• La tercera capa luego habla con la capa más interna, donde residen las entidades.

Ventajas de la “Arquitectura Limpia”

La “Arquitectura Limpia” le proporciona las siguientes ventajas:

• Comunicación y claridad: como puede ver, los casos de uso comercial son más fácilmente visibles. Esto proporciona una excelente claridad.
• Flexibilidad: ya no está atado a marcos, proveedores de bases de datos o proveedores de servidores de aplicaciones. Puede cambiar cualquiera de estos sin ningún impacto adverso.
• La arquitectura limpia ayuda en “Diseño dirigido por dominio” (DDD). DDD es importante para proyectos complejos ya que el enfoque está en el dominio central y la lógica asociada.
• La prueba se vuelve más fácil ya que puede configurar el alcance de la prueba de acuerdo con sus requisitos. Puede probar todas las interfaces e interacciones externas.

Lea más sobre estas ventajas en “La arquitectura limpia está gritando”.

¿Por qué considerar la “arquitectura limpia” en el desarrollo de Android?

Ahora reduzcamos nuestra discusión al desarrollo de Android. ¿Por qué debería considerar la “arquitectura limpia” aquí? Las razones son las siguientes:

• La “separación de preocupaciones” fue la premisa de diseño más fundamental con la que comenzamos. A estas alturas, puede ver cómo la “arquitectura limpia” aborda esto.
• Este patrón hace que la estructura del paquete sea fácil de navegar.
• Los evaluadores de aplicaciones de Android encuentran su trabajo más fácil con “Arquitectura limpia”. Hay un aumento notable en la cobertura de las pruebas.
• El código es más fácil de mantener.
• Habiendo compartimentado cuidadosamente la capa de presentación, la capa de lógica empresarial y las entidades, al equipo del proyecto le resulta más fácil avanzar con su trabajo.
• Las clases, incluidas las clases de prueba, están enfocadas.
• Los cambios en la interfaz de usuario pueden continuar según lo exijan los requisitos comerciales. Estos cambios y sus pruebas pueden continuar en un entorno estable.
• Los cambios estratégicos futuros son más fáciles ya que no hay dependencia del marco o de los proveedores de bases de datos.

Lea más sobre estas razones en “Una introducción rápida a la arquitectura limpia”.

¡La “arquitectura limpia” también tiene inconvenientes!

Ningún patrón de arquitectura de software está exento de inconvenientes. La “arquitectura limpia” también tiene su parte de escollos, que son los siguientes:

• Complejidad: La simple realidad con muchas aplicaciones es que la mayoría de las veces la aplicación solo se ocupa del consumo de datos. Esto significa que no hay mucha lógica comercial en juego. La mayoría de las operaciones son consultas de “Lectura” en una base de datos, mientras que algunas son operaciones de “Escritura”. La “arquitectura limpia” hace hincapié en los casos de uso. Si el arquitecto de software crea casos de uso para cada una de estas operaciones de “lectura” y “escritura”, ¡entonces la cantidad de casos de uso será realmente alta! En otras palabras, es probable que esté introduciendo mucha más complejidad de la que requiere la aplicación.
• Confundir la “arquitectura limpia” con la modularidad: está bien, a veces hay una lógica comercial real y no solo operaciones CRUD. Incluso entonces, si lo que le preocupa es hacer que su diseño sea modular, tiene otras formas de hacerlo. Aún podrá separar el código entre capas y la capacidad de prueba seguirá siendo correcta. Incluso aquí, puede evitar la complejidad de la “arquitectura limpia” y simplemente escribir código modular.
• Repeticiones: muchos expertos en desarrollo de software nos instan a evitar las repeticiones. Ahora, es inevitable con la “Arquitectura Limpia” donde tiendes a introducir más modelos estándar. Una vez más, la pregunta clave es si los necesita.
• Modelos duplicados: Esto está estrechamente relacionado con las trampas anteriores. Terminarás creando modelos similares debajo de cada capa. Debería preguntarse una vez más si realmente necesita esta complejidad.

Lea más sobre estos inconvenientes en “Desventajas de la arquitectura limpia”.

¿Está planeando implementar Clean Architecture en su proyecto de Android?

La “arquitectura limpia” ofrece varias ventajas, sin embargo, no es la proverbial varita mágica. En primer lugar, debe analizar si su aplicación es lo suficientemente compleja como para merecer este enfoque arquitectónico. Debe realizar un análisis cuidadoso de los casos de uso, las operaciones CRUD, las dependencias, etc. antes de planificar el uso de este enfoque.

A partir de entonces, debe prestar suficiente atención a la planificación de los diversos aspectos, como el flujo de datos a través de la capa de datos y varias capas. La capa de dominio es claramente la más importante, sin embargo, no puede tomar atajos mientras planifica las otras capas. Mantener todas las dependencias enfocadas hacia adentro tampoco es una tarea fácil.

Necesita la experiencia requerida en arquitectura de software. ¡Esa es una habilidad de nicho! Considere contratar a un socio de desarrollo de software confiable. Puedes leer nuestra guía “¿Cómo encontrar la mejor empresa de desarrollo de software?” antes de contratar a un socio para el desarrollo de este tipo.

Si aún está buscando un socio de desarrollo de software con experiencia, comuníquese con DevTeam.Space a través de este formulario rápido indicando sus requisitos iniciales de desarrollo de Android. Uno de nuestros administradores de cuentas lo ayudará a asociarse con nuestra comunidad de desarrolladores de software expertos en el campo para desarrollar código de calidad para su próxima aplicación de Android competitiva en el mercado.

Otras lecturas

Aquí tienes algunos artículos que también te pueden interesar:

Cómo escribir un documento de requisitos del producto [Step-by-Step]

Cómo escribir un documento de especificaciones funcionales

https://www.devteam.space/blog/how-to-use-blockchain-to-build-a-scalable-database/

Cómo usar la tecnología Blockchain para la identidad

Preguntas frecuentes