Patrón 2: Backend for Frontend para web y Android - JuanHerreraP/Proyecto-MISO-Solventa-Grupo-11 GitHub Wiki
Problema
El portal web y la aplicación Android consumen las mismas capacidades de negocio, pero tienen necesidades diferentes.
El portal web ofrece procesos completos para clientes, asesores y operaciones. Android necesita respuestas optimizadas para dispositivos móviles y funciones como biometría, cámara, geolocalización y modo offline.
Utilizar exactamente los mismos endpoints para ambos canales podría producir respuestas demasiado grandes, múltiples llamadas y acoplamiento entre las interfaces.
Solución
Se utiliza el patrón Backend for Frontend, creando una fachada especializada para cada canal:
- BFF Web: atiende las operaciones del portal web.
- BFF Móvil: atiende las operaciones de Android.
Los BFF reciben las solicitudes, consultan los servicios del dominio y adaptan las respuestas a las necesidades del canal.
No contienen reglas del negocio asegurador. Las reglas de cotización, perfilamiento, suscripción, pólizas, pagos y siniestros permanecen en los servicios compartidos.
Aplicación en Solventa
El BFF Web puede atender operaciones completas como:
- Cotización asistida.
- Suscripción.
- Administración de pólizas.
- Gestión de socios.
- Gestión de siniestros.
El BFF Móvil puede entregar respuestas adaptadas para:
- Consulta resumida de pólizas.
- Reporte de siniestros.
- Cotización móvil.
- Autenticación biométrica.
- Sincronización offline.
Ambos BFF reutilizan los mismos servicios de dominio y no duplican sus reglas.
Para reducir el esfuerzo, los BFF pueden implementarse inicialmente como módulos o controladores separados dentro del mismo despliegue en ECS Fargate.
Razonamiento
El patrón fue seleccionado porque web y Android representan experiencias diferentes. Separar sus fachadas permite modificar cada canal sin alterar el otro y reduce la cantidad de solicitudes realizadas por Android.
No se seleccionaron backends completamente independientes porque duplicarían reglas, datos y esfuerzo de mantenimiento.
Tácticas aplicadas
- Agregar solicitudes: combinar información de varios servicios en una respuesta.
- Reducir viajes de red: evitar múltiples solicitudes desde Android.
- Separar interfaces: aislar cambios específicos de web y móvil.
- Ocultar componentes internos: los clientes no conocen los servicios del dominio.
- Mantener contratos estables: versionar las respuestas de cada canal.
- Validar entradas: verificar los datos recibidos antes de enviarlos al dominio.
Relación con los ASR
- EC01 – Latencia: reduce viajes de red y permite respuestas adaptadas para cada canal.
- EC07 – Seguridad: evita exponer directamente los servicios internos.
- EC08 – Control de acceso: complementa la validación del gateway con controles específicos del canal.
- Facilidad de modificación: permite cambiar la aplicación Android sin modificar la experiencia web ni duplicar reglas del negocio.
Ventajas:
- Respuestas adaptadas para cada canal.
- Menos solicitudes desde Android.
- Evolución independiente de web y móvil.
- Servicios del dominio compartidos.
- Menor acoplamiento con las interfaces.
Limitaciones:
- Se deben mantener dos fachadas.
- Existe riesgo de duplicar lógica entre los BFF.
- Puede aumentar el número de componentes.
Diagrama
flowchart TD
Web["Portal Web"]
Mobile["Aplicación Android"]
Gateway["API Gateway"]
BFFWeb["BFF Web"]
BFFMobile["BFF Móvil"]
subgraph Domain["Servicios de dominio compartidos"]
Identity["Identidad y Consentimiento"]
Risk["Perfilamiento"]
Rating["Cotización"]
Underwriting["Suscripción"]
Policy["Pólizas"]
Payments["Pagos"]
Claims["Siniestros"]
end
Web -->|HTTPS| Gateway
Mobile -->|HTTPS| Gateway
Gateway --> BFFWeb
Gateway --> BFFMobile
BFFWeb --> Identity
BFFWeb --> Rating
BFFWeb --> Underwriting
BFFWeb --> Policy
BFFWeb --> Payments
BFFWeb --> Claims
BFFMobile --> Identity
BFFMobile --> Rating
BFFMobile --> Policy
BFFMobile --> Payments
BFFMobile --> Claims
Rating --> Risk
Rating --> Underwriting
Underwriting --> Policy