Modelos de arquitectura

Vista Funcional.

Proyecto	Elaboración	ID	Version	Modelo	Vista
DermoApp	Grupo 02	DA-001	1.0	Funcional	Componentes

Vista Despliegue

Proyecto	Elaboración	ID	Version	Modelo	Vista
DermoApp	Grupo 02	DA-002	1.0	Despliegue	Componentes

Vista Información

Proyecto	Elaboración	ID	Version	Modelo	Vista
DermoApp	Grupo 02	DA-003	1.0	Información	Componentes y clases

Dentro del diagrama de componentes revisamos con se maneja el flujo de información. En el diagrama de clases se especifica que contiene la información que fluye.

Componentes

Clases

Tácticas de arquitectura utilizadas para favorecer la disponibilidad.

• Arquitectura por Microservicios.
• Detección de fallas: Monitor Ping-Echo.
• Ocultar fallas: Cola de Mensajes.

Razonamiento sobre las principales decisiones de arquitectura tomadas en este modelo para favorecer la disponibilidad.

• Arquitectura por microservicios: Al tener esta arquitectura se favorece la disponibilidad al poder continuar con un sistema operable aun cuando uno o varios microservicios no estén disponibles.
• Monitor(PING-Echo): Se hace uso de esta táctica de disponibilidad de detección de fallas por la comunicación con los microservicios se establece a través de un API Gateway Service, que permite enmascarar las fallas que ocurran con alguna de los componentes monitoreando los llamados a los microservicios.​
• Cola de mensajes: Por medio de este componente se espera poder ocultar las fallas de algún microservicio en caso de estar indisponible permitiendo que la cola se encargue de manejar los mensajes pendientes.
• El despliegue de cada Microservicio es independiente favoreciendo la disponibilidad.

Tácticas de arquitectura utilizadas para favorecer la Escalabilidad.

• Estilo de arquitectura: Microservicios

Razonamiento sobre las principales decisiones de estilos arquitectura tomadas en este modelo para favorecer la Escalabilidad.

• Microservicios: Para nuestro caso vimos conveniente utilizar este estilo por las ventajas que tiene al implementarse que van acorde con los objetivos de la aplicación y nuestros ASRs.

Ventajas por las cuáles decidimos utilizar microservicios:

• Son más fáciles de mantener y testear, puesto que son servicios pequeños que hacen una tarea específica pero lo hacen bien.
• No están integrados en el sistema principal lo que hace que es microsercicio este poco acoplado, por tanto son más fáciles de desarrollar y desplegar. Pueden tener una escalabilidad independiente y se pueden aislar los fallos a un microservicio en concreto, en vez de una sección o funcionamiento de la aplicación, lo que facilita la mantenibilidad de la aplicación.
• No son necesarios cambios radicales en la tecnología que se utiliza, sino que para cada servicio se puede utilizar la tecnología más adecuada, y aunque en nuestro caso solo vamos utilizar una tecnología de desarrollo para el backend esto favorece la interoperabilidad y la comunicación con otros sistemas.
• Por parte del equipo de desarrollo es más fácil empezar a trabajar en algo en concreto ya que se puede ir a lo específico en vez de tener que entender todo el sistema para empezar a aportar, esto va muy de la mano con metodologías como Agile, devops, etc.

Patrones de arquitectura utilizados

• GOF - Patron Facade: Utilizamos el componente API Gateway como el único elemento de acceso. De manera que los componentes de la capa frontend no interactuan con ningún microservicio directamente. Esto permite enmascarar errores favoreciendo la disponibilidad del sistema.
• GRASP - Patrón High Cohesive: El patrón de "Alta Cohesión" se ve reflejado en la distribución de microservicios. Cada uno de los microservicios tiene una responsabilidad definida.
• SOLID - Patron SRP: El patron de "Responsabilidad Única" se refleja en los microservicios. Cada microservicio tiene una única responsabilidad. Este patron se asocia con el patron de "Alta Cohesión".