Propuesta de Proyecto
SISTEMA DE
FARMACIA
[Link]
PARA FARMACEUTICOS
Hecho por GRUPO 7
Integrantes - Grupo 07
HUARICACHA ESPINOZA CARLOS LAVERIANO
MASIAS, MELVIN PORROA, MELANI
LUIGI YULLI
SAAVEDRA HUAYTA, HUANCA LEYVA, SILVESTRE
MILAGROS ROLLER BRANDO CORNEJO, VICTOR
VICTORIA ANGEL
PISCOYA AGUILAR,
MARINA
CONTENIDO
VISIÓN DEL TIPO DE INTERFAZ
TIPO DE
PROYECTO Y UTILIZADO +
ARQUITECTURA
PROBLEMATICA PATRON DE
UTILIZADO
QUE RESUELVE ARQUITECTURA
BASE DE DATOS
DIAGRAMA DE UTILIZADA,
FRAMEWORKS
ARQUITECTURA DE DIAGRAMA DE BD
UTILIZADOS
LA APLICACIÓN + Y DIAGRAMA DE
VENTAJAS COMPONENTES
Visión del proyecto
Objetivo Principal: Desarrollar un sistema de logística automatizado para
[Link].
Objetivos Específicos:
Optimizar procesos de compras, ventas, inventarios y gestión de
clientes.
Mejorar la eficiencia operativa y reducir los errores humanos.
Implementar una arquitectura modular y escalable.
Integrar el sistema con otras plataformas mediante APIs y estándares
como JSON.
Beneficios Esperados:
Digitalización y automatización de operaciones clave.
Mejora en la disponibilidad de productos médicos esenciales.
Agilización de la toma de decisiones.
Problemática Problema 1: Procesos logísticos manuales e ineficientes.
que Resuelve Retrasos en la creación de solicitudes de compra,
cotizaciones y órdenes de compra.
Alta probabilidad de errores humanos y pérdida de
trazabilidad.
Problema 2: Falta de integración entre procesos.
Redundancia de datos y dificultad para obtener
información en tiempo real.
Desconexión entre la gestión de compras, ventas e
inventarios.
Impacto:
Baja competitividad.
Pérdida de eficiencia operativa.
Mala experiencia para los clientes.
Tipo de
arquitectura que
se uso
El proyecto utiliza una arquitectura
basada en microservicios
¿Por qué?
1. Modularidad: Los microservicios permiten desarrollar e implementar módulos de
forma independiente, evitando que errores en un servicio afecten al resto.
2. Escalabilidad: Cada módulo puede escalarse horizontalmente según sea necesario,
optimizando el uso de recursos.
3. Versatilidad: Posibilidad de usar diferentes tecnologías y lenguajes para adaptar cada
funcionalidad a la mejor solución técnica disponible.
4. Rapidez de desarrollo: Los microservicios, más pequeños y específicos, facilitan un
desarrollo ágil y el uso de contenedores acelera el despliegue.
5. Reutilización: La arquitectura desacoplada permite que el backend sirva a múltiples
interfaces, incluyendo aplicaciones web y móviles.
6. Intercambio ligero de información: El uso de JSON para las comunicaciones entre
cliente y servidor hace que las interacciones sean rápidas y eficientes.
ESTA ELECCIÓN RESPONDE A LA NECESIDAD DE ALTA DISPONIBILIDAD, ADAPTABILIDAD
MULTIPLATAFORMA Y UN DESARROLLO ÁGIL, SOLVENTANDO PROBLEMAS COMUNES EN
APLICACIONES MONOLÍTICAS Y GARANTIZANDO UNA EXPERIENCIA MÁS DINÁMICA Y EFICIENTE
PARA LOS USUARIOS.
HERRAMIENTAS UTILIZADAS
SQL SERVER SPRING SECURITY AZURE
Almacenar y gestionar la Flujo de autenticación Se desplego los
información del sistema de seguro usando OAuth2 con microservicios y el frontend
manera estructurada PKCE para el intercambio de en Azure App Services
tokens de forma segura
SPRING BOOT ANGULAR NODEJS
Para construir microservicios
modulares, SPRING CLOUD para construir una interfaz
para implementar el Para el desarrollo de algunos
de usuario, conectándola con
GATEWAY y SPRING DATA microservicios.
los microservicios a través de
JPA para la persistencia de APIs REST.
datos
Diagrama de la Arquitectura de Solución
VENTAJAS QUE POSEE EL SISTEMA
DISTRIBUIDO PLANTEADO
1 Modularidad y Mantenibilidad
2 Escalabilidad Horizontal
3 Despliegue Independiente y Eficiencia Operativa
4 Diversidad Tecnológica y Adaptabilidad
5 Resiliencia y Tolerancia a Fallos
6 Seguridad Robusta
7 Experiencia del Usuario y Accesibilidad
Tipo de Interfaz
Usada:No Acoplada
Una interfaz no acoplada (también
conocida como headless o
desacoplada) se refiere a un enfoque
en el cual el frontend y el backend
están completamente separados y no
dependen uno del otro para funcionar.
Características
1 2 3
FRONTEND
INDEPENDIENTE DESACOPLAMIENTO FLEXIBILIDAD
COMPLETO
El backend solo se encarga de Permite usar diferentes
gestionar los datos y la lógica El backend no maneja ni la tecnologías en el frontend (por
de negocio, mientras que el presentación ni la interfaz ejemplo, aplicaciones móviles,
frontend se comunica con el de usuario. sitios web, etc.) mientras se
backend a través de APIs mantiene un único backend.
(como RESTful APIs).
Ventajas Desventajas
Al tener dos componentes
El frontend y el backend pueden ser independientes, la integración y la
desarrollados y escalados gestión de la comunicación entre
independientemente. frontend y backend puede volverse
más compleja.
Para que el backend sirva diferentes
Permite integrar fácilmente el plataformas, puede ser necesario un
backend con diversas interfaces servidor de API robusto y bien
(web, móvil, IoT, etc.). estructurado, lo que incrementa la
carga de infraestructura.
Patrón de Arquitectura Usado:
Microservicios
Arquitectura que divide una aplicación en
servicios independientes, cada uno con su
propia responsabilidad.
Los servicios se comunican a través de APIs,
permitiendo la escalabilidad y la flexibilidad.
Características
1 2 3
DESACOPLAMIENTO CADA MICROSERVICIO ESCALABILIDAD
COMPLETO ENTRE ES RESPONSABLE DE INDEPENDIENTE DE
SERVICIOS UN CONJUNTO CADA SERVICIO.
LIMITADO DE
FUNCIONALIDADES.
Ventajas Desventajas
Complejidad en la gestión: Los
Alta disponibilidad y resiliencia: Un servicios independientes requieren
fallo en un servicio no afecta al una infraestructura más compleja y
resto del sistema. una buena estrategia de
comunicación.
Flexibilidad en el desarrollo: Los
Sobrecarga de red: Las
servicios pueden ser implementados
comunicaciones entre microservicios
y desplegados de forma
pueden generar latencia.
independiente.
Base de datos
utilizada y diagrama
de la BD
El proyecto utiliza Base de datos
SQL server
Diagrama de Base de Datos
Diagrama de Componentes
GRACIAS
POR SU
ATENCIÓN