Skip to content

Decisiones Arquitectónicas

Hugo Gutiérrez Tomás edited this page May 2, 2022 · 4 revisions

Decisión Arquitectónica 1

  • Título: Base de Datos a utilizar
  • Estado: Aceptada
  • Contexto: La aplicación requiere de una base de datos para almacenar la información
  • Decisión: Hemos llegado al acuerdo de utilizar MongoDB debido a la flexibilidad y libertad que ofrece.
  • Consecuencias: Nunca antes hemos trabajado con ella, por lo que tenemos que aprender a usarla.

Decisión Arquitectónica 2

  • Título: Uso de la biblioteca Mongoose
  • Estado: Aceptada
  • Contexto: Mongoose es una biblioteca de Nodejs que se basa en la definiciones de esquemas.
  • Decisión: Creemos que es una buena opción usar esta biblioteca debido a que permite normalizar la información de la base de datos sin sacrificar la flexibilidad que ofrece.
  • Consecuencias: Al igual que cualquier tecnología nueva, es necesario aprender a utilizarla.

Decisión Arquitectónica 3

  • Título: Backend
  • Estado: Aceptada
  • Contexto: Es necesario que la aplicación tenga Backend para que gestione los accesos a la bd.
  • Decisión: Se ha decidido usar Nodejs para implementarlo debido a que nos parece la opción más viable.
  • Consecuencias: Nunca hemos trabajado con Nodejs, por lo que debemos documentarnos.

Decisión Arquitectónica 4

  • Título: Framework de Nodejs
  • Estado: Aceptada
  • Contexto: El uso de un framework de Nodejs puede hacer más sencillo la implementación del Backend
  • Decisión: Hemos decidido utilizar Express, dado que ofrece muchas ventajas a la hora de usar Nodejs.
  • Consecuencias: Es necesario buscar información y documentarse bien para aprender a usarlo.

Decisión Arquitectónica 5

  • Título: Uso del stack MERN.
  • Estado: Aceptada.
  • Contexto: MERN es uno de los conjuntos de tecnologías más usados a la hora de realizar una aplicación web.
  • Decisión: Creemos que es una buena idea utilizar este stack dado que al ser uno de los más utilizados hace que haya una gran cantidad de información en internet en las cuales podemos informarnos.
  • Consecuencias: Es obligatorio que todo el equipo se familiarice con las tecnologías que presenta MERN.

Decisión Arquitectónica 6

  • Título: Librería de React
  • Estado: Aceptada
  • Contexto: Usar una librería para React hace que el desarrollo de la interfaz de usuario sea más llevadero.
  • Decisión: Hemos decidido utilizar Material-UI, debido que provee una gran cantidad de componentes totalmente personalizables a nuestro gusto.
  • Consecuencias: Es necesario mirar la documentación de cada uno de los componentes que queramos usar.

Decisión Arquitectónica 7

  • Título: Paquete React Router DOM
  • Estado: Aceptada
  • Contexto: Es un paquete que nos ayuda a realizar la navegación entre las distintas páginas que componen la aplicación.
  • Decisión: Lo hemos decidido utilizar debido a creemos que es una manera fácil de implementar las rutas dinámicas en nuestro Frontend
  • Consecuencias: Requiere mirar la documentación para implementarlo en nuestro código.

Decisión Arquitectónica 8

  • Título: API para calcular costes de pedidos
  • Estado: Aceptada
  • Contexto: La aplicación necesita un sistema que calcule el coste del envío de los pedidos en función de una dirección proporcionada.
  • Decisión: La API de Shippo es un buen ejemplo para llevar a cabo esta labor.
  • Consecuencias: Tenemos que implementar una llamada a la API en nuestra backend a la que le pasamos la dirección del usuario.

Decisión Arquitectónica 9

  • Título: Peticiones Frontend-Backend
  • Estado: Aceptada
  • Contexto: El Frontend debe envíar peticiones al Backend para realizar ciertos servicios, como por ejemplo el inicio de sesión de un usuario.
  • Decisión: Hemos decidido utilizar AXIOS, debido a que permite hacer peticiones asíncronas fácilmente.
  • Consecuencias: Consultar la documentación para ver cómo implementarlo en nuestra aplicación.

Decisión Arquitectónica 10

  • Título: Despliegue de la aplicación
  • Estado: Rechazada
  • Contexto: Es necesario que la aplicación esté desplegada para que pueda ser accesible.
  • Decisión: En un principio se decidió utilizar Heroku, debido a que parecía una buena opción, además de que ofrece un servicio gratuito.
  • Consecuencias: Es necesario buscar otro proveedor de servicios con los que desplegar nuestra aplicación.

Decisión Arquitectónica 11

  • Título: Despliegue de la aplicación
  • Estado: Aceptada
  • Contexto: Dado que Heroku finalmente no sirvió como despliegue, teníamos que buscar una nueva plataforma.
  • Decisión: Hemos buscado otra opción para el despliegue. Esta es AZURE.
  • Consecuencias: Todavía no lo hemos conseguido, por lo que nos toca seguir intentándolo.