Diseño de alto nivel: backend, API

![](

Backend:

• Nos permite interactuar con la información del servidor.

• Tiene alojados los datos y las reglas de negocio del sistema.

• Esta capa también es a la que le enviamos la información generada por el app.

API Service: Application Programming Interface.

• Permite una comunicación estructurada con el backend.

• REST: Representation State Layer.

Repository

• Es un patron de diseño que aísla la capa de comunicación en toda la aplicación.

• Permite consumir las APIs.

• Se encarga de tener una estrategia de almacenamiento y control de datos.

Persistence

• Bases de datos.

• Shared Preferences

• Memoria interna.

• Memoria externa.

DI Graph

Esta capa provee las dependencias a las diferente entidades por medio del patrón de inyección de dependencias.

En Android, hacemos esta gestión con Hilt y Koin.

App Module

• Separa responsabilidades.

• Mejora la compilación.

• On Demand Modules.

Flows

• Son la representación de la interacción del usuario con nuestra app.

• Aquí es donde usamos patrones de arquitectura visuales como MVVM, MVP, MVI, etc.

• Es toda la parte visual y de interacción de cara al usuario.

Backend Permite interactuar con la inf del serv. Tiene alojado los datos y reglas de negocio. Es donde enviamos la inf generada por la app. Pero para poder comunicarnos con esta capa necesitamos de las apis: API service aplication programming interface, una capa intermedia que me permite tener funcionalidades de algo, toda las funcionalidades publicas con las que puedo interactuar de una capa, y me permite tener la comunicarnos estructurada con el backend, y lo usamos con algo llamado REST Rest representation state layer, es un canal de comunicacion en el cual podemos hacer uso de estos datos del servidor. Repositorio Es un patron de disenio que aisla la capa de comunicacion de la aplicacion, permite consumir todas las apis que necesitamos porque es la capa de comunicacion, y tambien se encarga de tener la estrategia de almacenamiento y control de datos, la parte de cache, manejo de datos en la base de datos, como lo vamos a procesar, otra parte importante es: Persistencia Es como vamos a guardar los datos, que estrategias vamos a obtener, dentro de android tenemos cuatro formas de persistir: puede ser con bases de datos la usamos con un motor ligero llamado sqltite, tambien tenemos shared preferences para guardar las preferencias del usuario por ej si el usuario activa pone el modo dark, tambien tenemos la memoria interna la cual tenemos la seguridad de que existe, memoria externa puede que exista o no, aqui guardaremos archivos grandes y no sensibles, algo fundamental es:. Dl graph Aqui tenemos el grafo de inyeccion de dependencias, esta capa Provee las diferentes entidades por medio del patron de diseno e inyeccion de dependencias, como tal lo que hace es proveernos y crearnos todas las diferentes clases y componentes que nosotros necesitamos y el lo gestiona en tiempo de compilacion, crea todas las clases que necesitan ser proveidas por las diferentes entidades, si necesito una entidad como el repositorio no es necesario que yo lo haga manuealmente, simplemente con el grafo son creadas e inyectadas en los componentes que necesitan de estas,en android manejamos esto con las dos mas populares: hilt es una capa/graper de dagger2 y provee de una forma mas facil con notaciones todo este tipo de grafo de inyeccion dependencias, como tambien usamos kotlin como lenguage de programacion tambien tenemos koin que es el motor de inyeccion pero mas hacia el lado del lenguage de kotlin, tenemos esta capa aislada porque podemos usar un motor o el otro y la aplicacion funcionaria igual. App module Aqui separa responsabilidades de cada una de las capas de la aplicacion, mejorando la compilacion porque se compilaria solo el modulo que se modifico, on demand modules: si quiero que el ususraio tenga algo opcional que algunas secciones de la app sean opcionales de descargar. Flow Son los flujos del usuario, Es la representacion que tiene el usuario de la interaccion con la aplicacion, aqui tenemos como tal la interaccion del usuraio, con el viewmode y por ultimo con el repositorio, aqui se conectan todas las capas, es donde estan todas las partes de la arquitecturas.

Una aplicación móvil no puede tener las reglas del negocio, algunos motivos son:

• Están limitadas en cuanto a capacidad de procesamiento y espacio de almacenamiento. No pueden almacenar o procesar grandes cantidades de datos, que a menudo son necesarios para la lógica del negocio del sistema.
• No siempre tienen buena conexión a Internet. No podran acceder velozmente a datos o servicios almacenados en servidores remotos.
• Suelen utilizarse en lugares públicos. No siempre son seguras y que los datos sensibles pueden verse comprometidos.

Por ejemplo, una aplicación de banca móvil permite a los usuarios realizar tareas bancarias, como consultar su saldo, transferir dinero y pagar facturas. La lógica de negocio del sistema para estas tareas se encuentra en un servidor para garantizar que los datos esten seguros.

La lógica de negocio del lado del servidor para una aplicación de banca móvil podría incluir las siguientes tareas:

• Gestión de cuentas. Esto incluye tareas como la creación y gestión de cuentas de usuario, así como la verificación de las identidades de los usuarios.
• Procesamiento de transacciones. Esto incluye tareas como el procesamiento de pagos, transferencias y depósitos.

API Service Application programming Interface permite una comunicación estructurada con el backend REST: Representation State Layer Repository * Es un patrón de diseño que aísla la capa de comunicación en toda la aplicación * permite consumir las APIs. * Se encarga de tener una estrategia de almacenamiento y control de datos Persistence * Bases de datos: Es un motor sql para interactuar y guardar los datos * Shared Preferences: Guardar las preferencias de los usuarios * Memoria interna: Es toda la parte de la memoria que existe * Memoria externa: Puede ser extraíble o no

Backend * Nos permite interactuar con la información del servidor * Tiene alojados los datos y las reglas de negocio del sistema * Esta capa también es a la que le enviamos la información generada por la app.

Un servidor es una máquina o sistema que proporciona datos, servicios o recursos a otras computadoras (clientes) a través de una red. En el contexto de desarrollo de aplicaciones móviles, el servidor alberga el backend, gestionando las bases de datos y las reglas del negocio. Los clientes interactúan con el servidor a través de APIs, lo que les permite acceder a la información y funcionalidades de la aplicación. Este diseño es crucial para garantizar que las aplicaciones sean escalables y mantenibles.

Diseño de alto nivel una aplicación no funciona por si misma Backend Nos permite interactura con la información del servidor Tiene alojados los datos y las reglas de negocio del sistema

En el examen me marca mal esta respuesta, cuando casi lo dijo literal Cristian y según entendí la lógica así es : "2. ¿Para qué funciona una API? Es una capa que nos permite hacer llamados al backend para obtener información."