CleanArchitectureForAndroid
1.0.0
Este proyecto es una implementación floja de la arquitectura limpia como se presenta en mi libro, arquitectura limpia para Android. Es un proyecto nativo de Android escrito en Kotlin. Demuestra los principios clave presentados en el libro y cómo se aplican a un proyecto de la vida real.
Me esforzaré por mantener este proyecto actualizado y usarlo para demostrar las fortalezas de la arquitectura: escalabilidad , prueba y flexibilidad cuando se trata de elegir soluciones de terceros.
Sencillez
"¡ La complejidad introducida aquí es una exageración! "
Estoy de acuerdo. Si este fuera un proyecto final , al que nunca se agregaría una nueva funcionalidad, entonces la arquitectura limpia habría sido demasiado complicada por ello. Sin embargo, la realidad es que el proyecto móvil rara vez es definitivo. Comentarios de los usuarios, requisitos de marketing, nuevas tecnologías: todos estos factores y otros conducen a cambios continuos a casi todos los proyectos. Y así, lo que ahora puede parecer demasiada complejidad nos recompensará cuando llegue el momento del cambio. Esto será cuando brille la arquitectura limpia .
Como nota al margen: de alguna manera, he complicado intencionalmente este proyecto al introducir diferentes tecnologías. El objetivo era mostrar cómo, incluso en escenarios de la vida real, donde un proyecto puede haber crecido con el tiempo para incluir más de una solución tecnológica, la arquitectura aún funciona.
Mapeadores como clases versus funciones de extensión de mapeo
Al mapear entre modelos, tenemos varias opciones. La decisión principal es entre las clases de mapeadores y las funciones de extensión de mapeo.
Si bien las funciones de extensión son más concisas, usarlas para el mapeo limita nuestras elecciones de marcos de prueba (Mockito, por ejemplo, no puede agitar funciones estáticas).
¿Qué tal inyectar las funciones de extensión del mapeador? Podríamos hacer eso. Sin embargo, esto elimina los beneficios de la concisión casi por completo. También hace que la navegación a la implementación sea más difícil.
Y así, opté por las clases de mapeador de concreto ligeramente más detalladas.
Omitir los componentes de arquitectura de Google
El mayor problema con los componentes de arquitectura de Google es que filtran los detalles de Android en la capa de presentación. Esto evita que la capa de presentación sea verdaderamente agnóstica.
Otro problema con los componentes de la arquitectura es que dan demasiada responsabilidad al Modelo View. Hacen que el estado persistente que no posee, lo que lleva a posibles errores de sincronización de datos.
Por estas razones, mientras sigue a MVVM, este proyecto se basa en los flujos de Kotlin en lugar de Livedata , e implementa Pure ViewModels en lugar de los de Google.
Marco de burla
Tanto Mockito-Kotlin como Mockk se usan en este proyecto para demostrar cómo se vería el uso de cada uno.
Mi preferencia personal sigue siendo Mockito-Kotlin . Encuentro el código más fácil de leer y seguir cuando lo uso. Al momento de escribir, a juzgar por el número de estrellas en cada repositorio, la industria parece inclinarse hacia Mockk.
Me preguntaron sobre usar falsificaciones . He explorado las falsificaciones y las encontré demasiado detalladas y demasiado caras de mantener.
Marco de inyección de dependencia
Una parte crítica de la mayoría de las aplicaciones modernas, la inyección de dependencia (DI) nos ayuda a obtener los objetos que crean nuestra aplicación. También ayuda a manejar su alcance. Las opciones más populares en el mundo de Android son la empuñadura (que se construye en la parte superior de la daga) y Koin.
Pilt fue elegido por dos razones principales:
XML vs JetPack Compose
¿Por qué no ambos? Todavía tengo muchas preocupaciones sobre Jetpack Compose . Aun así, era importante para mí mostrar que la arquitectura presentada funciona bien, independientemente del mecanismo de UI elegido. Como ejercicio, lo invito a intentar reemplazar la capa de UI de composición a XML o viceversa sin actualizar la capa de presentación.
Arquitectura limpia para Android en Amazon
Arquitectura limpia en el blog Clean Coder
Las contribuciones a este proyecto son bienvenidas. No dude en informar cualquier problema o bifurcación para realizar cambios y plantear una solicitud de extracción.
Este proyecto se distribuye bajo los términos de la licencia MIT. Vea la licencia.md para más detalles.
