MVFuncional - shiomar-salazar/MISW-PF-Grupo1-Backend GitHub Wiki

Vista Funcional

Modelo

Diagrama Funcional_C C

Enlace para ver mejor el diagrama

Subarquitecturas - Microservicios

Diagrama Funcional_C C_subarquitecturas

Enlace para ver mejor el diagrama

Razonamiento sobre Principales decisiones de Diseño

Estilo Utilizado

Para esta arquitectura se utilizo el estilo de microservicios. Cada microservicio es relativamente pequeño, se encarga de tareas específicas y se ejecutan independientemente, lo que favorece atributos de calidad como la alta cohesión, bajo acoplamiento, facilidad de modificación, facilidad de mantenimiento y escalabilidad.

Tacticas Utilizadas

  1. Tacticas para facilidad de modificacion
  • Usar intermediarios: Esta tactica evita que los componentes interactuen directamente, de forma que los componentes son mas facil de reemplazar y modificar.

  • Incrementar cohesion: Los componentes son disenados para realizar una tarea especifica y bien definida. A mayor cohesion es mas probable que un cambio no afecte a otros componentes

  • Reducir acoplamiento: Los componentes son disenados para que la dependencia con otros componentes sea minima o nula. A menor acoplamiento es mas probable que un cambio no afecte a otros componentes.

Patrones Utilizados

  • Alta cohesion (patron GRASP): Se busca que las operaciones que provee un objeto esten altamente relacionadas entre si. Se favorece la facilidad de mantenimiento del software, su reutilizacion y el bajo acoplamiento. Por ejemplo los componentes gestor PlanNutricional y gestor Entrenamiento cada uno tiene una responsabilidad clara y bien definida, de forma que no dependen de otros componentes.

  • Bajo acoplamiento (patron GRASP): Se busca minimizar la dependencia entre objetos para facilitar el mantenimiento, reuso y eficiencia de los objetos. Por ejemplo el componente gestor Notificaciones se comunican por mensajes con el resto de los componentes, lo que lo hace bajamente acoplado y mas facil de reemplazar y modificar sin afectar a otros componentes.

  • Unica responsabilidad (patron SOLID): Cada componente tiene una responsabilidad sobre solo una parte de la funcionalidad provista por el software. Por ejemplo el componente Notificaciones es el unico objeto encargado de enviar notificaciones al usuario. Actua como un centro de recibo y despacho de mensajes que otros objetos generan y que requieren ser enviados a los clientes.

  • Fachada (patron GOF): Este patrón utiliza el componente Load Balancer que proporciona un punto de entrada único para acceso a los microservicios de la logica de negocio, actuando como un proxy inverso, enrutando solicitudes de clientes a servicios.