VisionArq - shiomar-salazar/MISW-PF-Grupo1-Backend GitHub Wiki

Visión de arquitectura

Problema de negocio

SportApp es una empresa que desea incursionar en el mercado con una solución tecnológica dirigida hacia el público latinoamericano, con la cual pueda según sus características geográficas, culturales, fisiológicas y alimenticias, generar diferentes estrategias que se adapten y satisfagan las necesidades reales de los usuarios, enfocadas en el bienestar y la salud de cada uno. Por lo tanto, SportApp no solo quiere brindar funcionalidades que hagan lo mismo que las plataformas existentes, sino que quiere brindar una experiencia mucho más personalizada a los usuarios latinoamericanos, ya que las necesidades de entrenamiento/alimentación son diferentes según el lugar geográfico. Adicionalmente se incluye el suministro de todos aquellos servicios complementarios (transporte, alimentación, acompañamiento médico, sesiones con los entrenadores, rutinas de entrenamiento personalizadas, entre otros) necesarios para la realización de sus actividades deportivas.

Objetivos de los stakeholder

  • Permitir la asociación con terceros que facilite ampliar la oferta de servicios que se pueden ofrecer a los deportistas.​
  • Personalizar la experiencia de los entrenamientos y servicios para los deportistas Latinoamericanos.​
  • Mantener un monitoreo constante a las actividades de los deportistas, lo que permitiría generar alertas, reducir los riesgos durante la rutina y motivar a los deportistas.​
  • Posicionarse como una de las principales aplicaciones del segmento de salud y bienestar basados en el ejercicio y la buena alimentación de los deportistas latinoamericanos.​

Riesgos

  • Cumplimiento de normativas legales y regulaciones en cada país latinoamericano donde se desee iniciar operaciones.​
  • Integraciones con otros sistemas externos.​
  • Firmas de contratos con prestadores de servicios profesionales para los deportistas.​
  • Escalabilidad y rendimiento de la aplicación cuando se experimente un crecimiento rápido en el número de usuarios o altos picos de uso.​
  • Retrasos en el cronograma del proyecto por temas externos o mala planeación.

Restricciones de negocio y tecnología

Restricciones de Negocio

  • El equipo de arquitectura pueden ser 4 integrantes, el cual va a ser contratado por 8 semanas por temas de presupuesto.​
  • El equipo de desarrollo solo pueden ser 4 integrantes, el cual va a ser contratado por 8 semanas por temas de presupuesto.​
  • El diseño de la arquitectura del sistema se debe elaborar en un tiempo máximo de 8 semanas, incluyendo pruebas de concepto y experimentos de arquitectura.​
  • La implementación de las funcionalidades priorizadas según el alcance establecido se llevará a cabo en un tiempo máximo de 8 semanas.​
  • Se deben cumplir con las regulaciones y normativas asocias a la privacidad de los datos personales y médicos.

Restricciones de Tecnología

  • El lenguaje de programación para la implementación de los servicios será Python.​
  • Para la persistencia de datos se hará uso de PostgreSQL como base de datos relacional.​
  • Todos los servicios que hacen parte del Backend se implementaran a través de contendores en GKE o Cloud Functions.​
  • Todos los servicios deberán tener un set de pruebas unitarias implementado con Pytest.​
  • Se deberá implementar un flujo de CI/CD con Cloud Build y Cloud Code.​
  • Se hará uso de GCP como proveedor en la nube.​
  • La aplicación web se implementará en Angular.​
  • La aplicación móvil se implementará en Kotlin.

Estimación de Esfuerzo

Equipo de Arquitectura:​

  • 4 Arquitectos, 8 horas productivas por semana por arquitecto durante 8 semanas.​
    Total de 256 horas/hombre.​

Equipo de Desarrollo:​

  • 4 Desarrolladores 8 horas productivas por semana por arquitecto durante 8 semanas​
    Total de 256 horas/hombre.

Modelo de contexto

image

Modelo de dominio

image

Entidades

  • Usuario: Corresponde a los usuarios "deportistas" que usaran la aplicacion.
  • Prestadores: Corresponde a los diferentes prestadores de servicios profesionales como Entrenadores, Nutricionistas, Deportologos entre otros.
  • Servicios: son los servicios que puede ofrecer cualquier prestador y que son escogidos por los los usuarios "Deportistas".
  • Plan: son los tipos de planes de alimentacion, entrenamiento.
  • Pagos: pagos que un usuario realiza por los servicios seleccionados y por el tipo de licencia que tenga en la aplicacion.
  • Calendario: calendarios personalizados para cada usuario con las indicaciones de los ejercicios a realizar y la dieta recomendada.
  • Ejercicio: Rutina de entrenamiento que debe realizar una persona segun el dia del calendario.
  • Eventos: Eventos deportivos ofrecidos por algun prestados como Carreras, convenciones entre otros.

Nota: Se comparte url del Sharepoint de Uniandes para una mejor visualización: Modelo de Dominio

Modelo de componentes

En este modelo se visualiza a muy alto nivel la forma en que se estructura y organizan los diferentes componentes que hacen parte de SportApp, adicional a esto permite observar las interfaces, el tipo de comunicación y la relaciones entre estos. Se tienen 3 grupos identificados que encapsulan los componentes con base a su afinidad en el sistema:

Grupo de componentes de Frontend:

  • Componente aplicación web: hace referencia a la aplicación Web de SportApp.
  • Componente aplicación móvil: hace referencia a la aplicación Móvil de SportApp.

Grupo de componentes de Backend:

  • Subgrupo de componentes de acceso:
    • Componente gestor autenticación: hace referencia al componente encargado de gestionar el acceso a las diferentes aplicaciones del sistema.
  • Subgrupo de componentes de administración:
    • Componente gestor usuarios: hace referencia al componente encargado de suministrar el CRUD asociado a un usuario.
    • Componente gestor especialistas: hace referencia al componente encargado de suministrar el CRUD asociado a un especialista (entrenadores, deportólogos, entre otros).
    • Componente gestor proveedores: hace referencia al componente encargado de suministrar el CRUD asociado a un proveedor.
    • Componente gestor proveedores: hace referencia al componente encargado de suministrar el CRUD asociado a un proveedor.
    • Componente gestor eventos deportivos: hace referencia al componente encargado de suministrar el CRUD asociado a un evento deportivo.
  • Subgrupo de componentes Core (componentes que forman parte del objetivo del sistema, el valor agregado y la diferencial con otros sistemas existentes):
    • Componente gestor logístico: hace referencia al componente encargado de gestionar la logística correspondiente a un evento deportivo.
    • Componente gestor notificaciones: hace referencia al componente encargado de gestionar las diferentes notificaciones que se enviaran al usuario.
    • Componente gestor entrenamientos: hace referencia al componente encargado de gestionar los diferentes entrenamientos que se le asignan a un usuario con base a sus características.
    • Componente gestor integrador de aplicaciones: hace referencia al componente encargado de integrarse con diferentes aplicaciones de apoyo deportivas como Strava o Trainingpeaks.
    • Componente gestor ventas: hace referencia al componente encargado de gestionar el pago de un producto/servicio.
    • Componente gestor plan nutricional: hace referencia al componente encargado de gestionar los diferentes planes nutricionales que se le asignan a un usuario con base a sus características.
    • Componente gestor monitoreo: hace referencia al componente encargado de monitorear y analizar los diferentes comportamientos del usuario cuando está realizando sus actividades deportivas.
  • Subgrupo de componentes de consultas/reportes:
    • Componente gestor consultas: hace referencia al componente encargado de realizar las diferentes consultas solicitadas por los usuarios del sistema.
    • Componente gestor reportes: hace referencia al componente encargado de realizar los diferentes reportes solicitados por los usuarios del sistema.

Grupo de componentes externos:

  • Componente aplicaciones de registros deportivos: hace referencia a las aplicaciones externas de apoyo deportivas con las cuales se podrá integrar el sistema, como Strava o Trainingpeaks.
  • Componente pasarela de pagos: hace referencia a las aplicaciones externas con las cuales el sistema realizara un pago de un producto/servicio.
  • Componente sistema de notificaciones al usuario: hace referencia a las aplicaciones externas con las cuales el sistema realizara el envio de notificaciones a los usuarios.
  • Componente herramientas de análisis de datos: hace referencia a las herramientas externas con las cuales el sistema se apalancará para realizar el análisis de datos asociados a las características del usuario.
  • Componente sistema de navegación externa GPS: hace referencia al sistema de navegación de GPS que permitirá realizar el monitoreo del recorrido realizado por el usuario mientras efectúa sus actividades deportivas.

Nota: Se comparte url del Sharepoint de Uniandes para una mejor visualización: ComponentsDiagram_SportApp.jpg

Modelo de despliegue

En este modelo se visualiza a muy alto nivel la propuesta inicial a nivel de infraestructura necesaria para el despliegue y funcionamiento adecuado de SportApp. Como primera decisión de arquitectura en común acuerdo se estableció a Google Cloud Platform como proveedor en la nube, debido a que el equipo cuenta con un poco más de experiencia trabajando en dicha plataforma. Por lo tanto, se hará uso en un 100% de los diferentes servicios y capacidades ofertadas por GCP. A continuación, se describen los servicios de GCP que se utilizaran para resolver una parte especifica de los requerimientos y/o necesidades de infraestructura:

Despliegue del frontend:

  • Cloud Storage: Es un servicio de almacenamiento de objetos, en el cual se alojará la aplicación web implementada con Angular.

Despliegue del backend:

  • Load Balancer: Es un balanceador de carga que permite distribuir el tráfico de las peticiones HTTP entrantes. Este balanceador de carga se implementará de forma global y se encargar de re direccionar las peticiones a las diferentes zonas de disponibilidad.
  • Google Kubernentes Engine: Es un servicio Kubernetes administrado, en el cual se desplegarán los contenedores con las aplicaciones más robustas del proyecto.
  • Cloud Functions: Es un servicio informático sin servidor, en el cual se implementarán funcionalidades específicas y granulares del sistema, que necesitan responder a eventos.
  • Cloud SQL: Es un servicio de base de datos relacional totalmente administrado, en el cual se implementarán las estructuras y la persistencia de datos necesarias para el funcionamiento de las aplicaciones.
  • Cloud Pub/Sub: Es un servicio de mensajería que permite el intercambio de datos de forma asíncrona. Este servicio se utilizará para los flujos de las aplicaciones que tengan dicha característica.

Flujo de integración continua y despliegue continuo (CI/CD):

  • Cloud Source Repository: Es un repositorio Git privado, en el cual se almacenará el código fuente de los componentes de software desarrollados por el equipo.
  • Cloud Build: Es una plataforma de CI/CD sin servidor, en la cual se implementarán los flujos automatizados para la realización de las pruebas, construcción de imágenes y envio al repositorio de imágenes.
  • Cloud Container Registry: Es un registro de imágenes de contenedores privado, en el cual se alojarán las imágenes de los servicios.
  • Cloud Deploy: Es una herramienta que permite automatizar y gestionar la implementación de aplicaciones en la nube.

Disponibilidad y latencia de las aplicaciones del Backend:

  • Con el fin de generar una baja latencia se tomó la decisión de usar la Región us-central1, ya que es la región que se encuentra más cerca al público objetivo de SportApp, que son los usuarios latinoamericanos. Por otra parte, para garantizar una alta disponibilidad de las aplicaciones, dentro de la región us-central1 se implementan múltiples zonas (us-central1-a, us-central1-b y us-central1-c) y se hará uso de un Balanceador HTTPS Global que se encargará de redirigir el trafico correspondiente.

Nota: Se comparte url del Sharepoint de Uniandes para una mejor visualización: DeploymentDiagram_SportApp.jpg

⚠️ **GitHub.com Fallback** ⚠️