-
Notifications
You must be signed in to change notification settings - Fork 1
sprint3 documento tecnico
A partir del diagrama de despliegue de los servicios de negocio y de infraestructura implementados en el proyecto, se procede con la revisión de los elementos de arquitetectura definidos en la visión.

- Mantener una alta cohesión
- Mantener un bajo acoplamiento
- Reducir el tamaño de los módulos - Dividir módulos.
Para favorecer el atributo de facilidad de modificación, se diseñaron e implementaros componentes tipo microservicios, aplicando tácticas de componentes de de bajo tamaño, con única responsabilidad, bajo acoplamiento y alta cohesión, permitiendo que a futuro los cambios solicitados a futuro impacten solo los servicios requeridos, sin genear impacto en el resto de servicios del sistema.
- Detectar fallas: healthcheck
- Enmascarar fallas: identificar y retirar componente defectuoso
- Recuperación de fallos: reinicio de componente
Para favorecer el atributo de disponibilidad se toma la decisión de implementar el estilo de arquitectura Microservicios y aprovechar las funcionalidades de Elastic Container Service para la detección de fallas, el retiro de componente(s) defectuoso(s) y su respectivo reinicio.
- Manejo de recursos compartidos - múltiples copias de computación
- Manejo de recursos compartidos - múltiples copias de datos
Para favorecer la escalabilidad, dentro de la táctica de manejo de recursos compartidos, se implementan múltiples copias de computación y múltiples copias de datos con el objetivo de crecer y decrecer horizontalmente de forma tal que permita atender la demanda de ls diferentes servicios.
Para múltiples copias de computación, se definen los parámetros de auto-scaling (capacidad mínima y máxima, además de la política de uso de memoria y cpu) dentro del archivo de variables terraform https://github.com/andergcp2/backend-proyecto-final/blob/main/aws-tf/terraform.tfvars, para su respectivo aprovisionamiento
"pruebas-taker" = {
name = "pruebas-taker"
is_public = true
container_port = 80
host_port = 80
cpu = 256
memory = 512
desired_count = 1
alb_target_group = {
port = 80
protocol = "HTTP"
path_pattern = ["/tests-taker*"]
health_check_path = "/tests-taker/ping"
priority = 1
}
auto_scaling = {
max_capacity = 2
min_capacity = 1
cpu = {
target_value = 75
}
memory = {
target_value = 75
}
}
}
Patrón CQRS
Usando AWS AuroraDB para Queries y RDS para Commands. Busca optimizar la velocidad de las consultas y las operaciones de modificación, favoreciendo atributos relacionados al desempeño.
Nos permite implementar y optimizar de manera independiente las responsabilidades de comandos y queries, una parte del equipo se puede hacer cargo del modelo de escritura mientras otros se dedican a la interfaz de usuario y al modelo de lectura.
- Avance-1 - Charts
- Avance-1 - Devops
- Avance-2 - Charts
- Avance-2 - Devops
- Cierre - Charts
- Cierre - Devops
- Cierre - Retrospectiva
- Cierre - Instructivo Usuario
- Cierre - Documentación Técnica
- Objetivos, Restricciones y Requisitos
- Escenarios de calidad
- Visión de Arquitectura
- Estilos Tácticas Patrones
- Experimento1
- Experimento2
- Resultados Experimentación