Arquitectura del flujo demo¶
La APK mantiene datos locales para validar experiencia y diseño sin backend. La estructura evita que Compose dependa directamente del origen de datos para que un proveedor remoto pueda incorporarse sin reescribir pantallas.
Capas¶
| Capa | Responsabilidad | Ubicación |
|---|---|---|
| Presentación | Compose, navegación, estados de formulario y copy | ui/ |
| Casos de uso | Orquestación de una intención de usuario | domain/usecase/ |
| Contratos | Interfaces pequeñas por capacidad | domain/repository/ |
| Datos demo | Estado observable, reglas demo y fixtures | data/local/ |
| Composición | Selección del proveedor activo | data/local/AppRepositories.kt |
Contratos actuales¶
AccountRepository: usuario y gate KYC.PackageRepository: prealertas, tracking, recepción y atención pendiente.ShippingRepository: consolidaciones, cotizaciones, pago y despacho.SupportRepository: servicios e incidencias.NotificationRepository: lectura y listado de notificaciones.
DemoSessionRepository implementa estos contratos durante la demo. AppRepositories es el único punto que selecciona esa implementación.
Sustitución por backend¶
- Crear proveedores remotos que implementen cada contrato, por ejemplo
RemotePackageRepository. - Mantener los modelos de dominio y los casos de uso; convertir DTOs exclusivamente dentro de
data/remote/. - Cambiar la composición en
AppRepositorieso introducir un contenedor de inyección cuando exista una dependencia justificada. - No introducir llamadas HTTP, DTOs ni reglas de negocio en composables.
Reglas de mantenimiento¶
- Una pantalla no modifica colecciones del repositorio directamente.
- Una regla que afecte a más de una pantalla pertenece al repositorio o a un caso de uso.
- Los estados y mensajes visibles se derivan de modelos de dominio, no de fixtures duplicados.
- Las acciones demo deben indicar que son simuladas y no prometer persistencia o validación real.