Decisiones arquitectónicas

Decisiones arquitectónicas tomadas

Decisión arquitectónica 1

• Título: Base de datos
• Estado: Aceptada
• Contexto: Se necesita una base de datos para guardar la información sobre los usuarios, productos y pedidos.
• Decisión: Se ha acordado escoger MongoDB combinado con MongoDB Atlas dado que aporta una mayor flexibilidad a la hora de guardar la información.
• Consecuencias: Utilizar un tipo de base de datos nueva para el equipo y buscar una API para gestionar la base de datos.

Decisión arquitectónica 2

• Título: Unificación de 'back-end' y 'front-end'
• Estado: Aceptada
• Contexto: Se necesita poder unificar las distintas partes del proyecto.
• Decisión: Se ha acordado utilizar la arquitectura 'MERN' para la comunicación entre 'back-end' y 'front-end'. M (MongoDb), E (expressJS), R (React), N (NodeJS).
• Consecuencias: Todos los miembros del equipo deben de familiarizarse con esta arquitectura.

Decisión arquitectónica 3

• Título: Conexión a MongoDB
• Estado: Aceptada
• Contexto: Se necesita una API con la que poder conectarse a nuestro clúster.
• Decisión: Se ha acordado utilizar la API 'mongoose', dado que permite conectarse al clúster de una forma sencilla.
• Consecuencias: Aprender a integrar / utilizar esta API.

Decisión arquitectónica 4

• Título: Administración de peticiones
• Estado: Aceptada
• Contexto: Se necesita una API que nos permita realizar peticiones a 'back-end' desde 'front-end'.
• Decisión: Se ha acordado utilizar la API 'axios', dado que permite realizar peticiones asíncronas al 'back-end'.
• Consecuencias: Todos los miembros del equipo deben aprender a utilizar 'axios'.

Decisión arquitectónica 5

• Título: Despliegue de la aplicación
• Estado: Rechazada
• Contexto: Se necesita una plataforma que permita desplegar nuestra aplicación para que sea accesible a cualquier persona.
• Decisión: Se ha acordado escoger Heroku como plataforma de despliegue, dado que ofrece este servicio de forma gratuita.
• Consecuencias: Aprender a desplegar un multi-respositorio en Heroku.

Decisión arquitectónica 6

• Título: Almacenamiento de imágenes
• Estado: Aceptada
• Contexto: Se necesita un host que nos permita guardar las imágenes de los productos.
• Decisión: Se ha acordado utilizar como host 'Cloudinary' dado que ofrece este servicio de forma gratuita.
• Consecuencias: Aprender a integrar esta API dentro de nuestro proyecto.

Decisión arquitectónica 7

• Título: Despliegue de la aplicación
• Estado: Aceptada
• Contexto: Dado que Heroku ha sido rechazada, se necesita buscar una nueva plataforma de despliegue.
• Decisión: Se ha acordado escoger AWS como nueva plataforma de despliegue, dado que ofrece un servicio de despliegue en máquinas virtuales.
• Consecuencias: Aprender a ejecutar imágenes de Docker en máquinas virtuales y guardar variables de entorno en GitHub.

Decisión arquitectónica 8

• Título: Ejecución de pruebas
• Estado: Aceptada
• Contexto: Se necesita una base de datos en la que poder ejecutar pruebas sin que afecten al proyecto.
• Decisión: Se ha creado otro clúster de MongoDB.
• Consecuencias: Crear una nueva conexión para la ejecución de tests.

Decisión arquitectónica 9

• Título: Envío de correos electrónicos
• Estado: Aceptada
• Contexto: Se necesita una API que nos permita enviar un resumen de un pedido al cliente.
• Decisión: Se ha acordado utilizado 'nodemailer', dado que permite el envío de correos electrónicos desde distintos hosts (en nuestro caso Gmail).
• Consecuencias: Aprender a utilizar la API y configurarla para poder enviar correos con nuestra cuenta de Gmail.

Decisión arquitectónica 10

• Título: Notificaciones al usuario
• Estado: Aceptada
• Contexto: Se necesitan notificaciones emergentes para informar a los usuarios.
• Decisión: Se ha acordado utilizar la librería 'react-toastify'.
• Consecuencias: Aprender a utilizar esta librería y la variedad de notificaciones existentes.

Decisión arquitectónica 11

• Título: Almacenamiento en sesión de objetos
• Estado: Aceptada
• Contexto: Se necesita guardar en sesión objetos.
• Decisión: Se ha acordado utilizar la librería 'react-client-session'.
• Consecuencias: Aprender a utilizar esta librería.

Decisión arquitectónica 12

• Título: Rutas URL
• Estado: Aceptada
• Contexto: Se necesita crear las rutas de la aplicación y acceder a rutas concretas.
• Decisión: Se ha acordado utilizar la librería 'react-router-dom'.
• Consecuencias: Aprender a utilizar esta librería para poder crear las rutas de la aplicación y enlaces a las rutas.