La fecha límite de entrega del proyecto es el 21 de febrero de 2022 a las 11:59 PM Hora Colombia (GMT-5).

Siga las instrucciones a continuación para crear los entregables que serán calificados en el proceso de evaluación.

Prerrequisitos

Para cumplir con las actividades del proyecto es necesario que cuente con ciertas herramientas instaladas en su máquina personal.

• Postman (https://www.postman.com/)
• Git (https://git-scm.com/). No olvide configurar su usuario de git para que las entregas estén marcadas con este.
• Python 3.9 (https://www.python.org/)
• IDE de su elección. Puede definirlo con su equipo de trabajo.
• Docker https://www.docker.com/
• gcloud sdk https://cloud.google.com/sdk/docs/install

Objetivos

• Aplicar los conocimientos adquiridos para el diseño de una aplicación haciendo uso de microservicios.
• Implementar patrones de microservicios para cumplir con requerimientos del negocio, teniendo en cuenta buenas prácticas que beneficien la cohesión, resiliencia y consistencia de la información.

El equipo de ingeniería se ha reunido para determinar cuál es el siguiente paso en el desarrollo de la aplicación. El objetivo en este momento es tomar decisiones que le permitan al negocio entregar valor rápidamente, y a su vez permitir que el equipo de desarrollo se acople a las nuevas tecnologías que se están implementando en la compañía. Para ello se tomaron tres decisiones importantes:

1. Se ha decidido que vamos a convivir con el monolito; este seguirá ofreciendo los servicios que expone actualmente, pero no se extenderá.
2. Las nuevas funcionalidades se desarrollarán haciendo uso de la arquitectura de microservicios, estos microservicios hablarán con el monolito siempre que lo requieran y no duplicarán sus funcionalidades actuales.
3. Para las nuevas funcionalidades se hará uso de patrones síncronos.

Teniendo como base estás decisiones, en conjunto con su grupo de trabajo usted debe:

1. Hacer un diseño general del mapa de microservicios que soportarán el sistema a futuro.
2. Hacer un diseño en específico de los componentes necesarios para satisfacer dos necesidades de negocio.
3. Implementar los componentes que permitan cumplir con las necesidades de negocio seleccionadas.
4. Probar y sustentar el funcionamiento de sus componentes en ejecución sobre el proveedor de nube.

Durante la semana 3 se recomienda avanzar con las dos primeras partes del proyecto, e iniciar la construcción de componentes descritos en la parte 3.

En una reunión con el equipo completo de la compañía, se hizo una descripción de las necesidades y expectativas con respecto a lo que el sistema debe ofrecer en el futuro. El resumen de esa conversación es la siguiente:

• El equipo de marketplace tiene un interés en conocer los gustos de los usuarios y con eso poder ofrecer funcionalidades para incrementar las ventas en la plataforma. Para ellos resulta muy importante que los usuarios puedan acceder y ver los distintos productos que se ofrecen, pero además que puedan gestionar los productos deseados, realizar preguntas sobre los productos, calificarlos y poder hacer trazabilidad de los usuarios: con cuáles productos interactúan, el tipo de interacción (carrito de compras, comentario, visitar página, lista de deseos) y las fechas de esas interacciones.
• El equipo financiero se enfoca en los ingresos y egresos de la compañía, por lo que están interesados en la información de la venta de los productos y los usuarios que los han comprado, las facturas de esos productos y el estado de las mismas, además de los medios de pagos utilizados, y los bonos de descuento aplicados. Por otro lado, es de suma importancia tener acceso a los datos bancarios de los proveedores y encargados de logística, para realizar el pago de las comisiones de venta y transporte.
• Por último, el equipo de logística se enfoca en la gestión de los pedidos, tener la certeza de cómo va un pedido, en qué fase está, cúal encargado de logística se encargará de su transporte y si el cliente final lo ha recibido o no. Por ello, su interés está en la gestión de proveedores, donde están ubicados geográficamente, sus datos de contacto, cuáles son los productos que ofrecen y como es el proceso de fabricación de esos productos; fases de fabricación, y tiempos que toma cada fase. También están interesados en conocer más de cada cliente, en específico en donde está ubicado geográficamente.

Con esta información se espera un diseño general de cómo sería la estructura de los microservicios con los que se respondería a las necesidades del negocio. A continuación, se detalla los entregables de este punto.

25 puntos

Con la información presentada en el segmento anterior usted debe:

[12 puntos] Modelo de contexto

Crear un modelo de contexto donde se presenten los conceptos del negocio y la relación entre ellos en términos de agregados (aggregates) y contextos (bounded context). Para este punto tenga en cuenta los siguientes lineamientos:

• En el modelo se debe tener en cuenta los componentes actuales de la aplicación (el monolito).
• Este modelo debe ir acompañado con una tabla glosario donde se explique cada agregado con los datos que contiene. La tabla debe tener el siguiente formato:

• Junto con el modelo se debe encontrar una tabla en la que se explica cada relación que existe entre dos agregados, sean o no sean del mismo contexto. La tabla debe llevar el siguiente formato:

[13 puntos] Modelo de componentes

Haciendo uso del modelo anterior, crear un primer modelo de componentes (vista funcional) que presente los microservicios del sistema. Para este punto tenga presente:

• En el caso que considere tener más de un agregado en un microservicio, debe sustentar su decisión en términos de: cohesión, acoplamiento, y responsabilidades asociadas. Sustente este punto por medio de una tabla que contiene la siguiente información.

• Para este punto no detalle los conectores entre microservicios, estos pueden ser asíncronos o síncronos pero no es necesario definirlos en el momento.
• Debe tener en cuenta en el diagrama cuáles microservicios se comunican con el monolito, detallando los servicios que consumen.
• Debe representar claramente cuáles microservicios podrán ser consumidos por un usuario final y cuáles no. Pueden existir microservicios de consumo interno que no pueden ser alcanzados desde fuera del sistema.
• Dado que la seguridad es un factor importante en nuestros diseños, todos los microservicios que no son internos deben gestionar y hacer uso de la sesión del usuario.
• El modelo debe tener convenciones.

Criterios de Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• Completitud: Se evaluará que ambos diagramas contengan los conceptos descritos en el enunciado, y se describen haciendo uso correctamente de la relación entre agregados y contextos.
• Justificación: Se evaluará que ambos diagramas cuenten con la explicación de cada decisión de diseño y que estás decisiones no vayan en contra de los principios de una aplicación nativa.
• Efectividad: Se evaluará que los diseños presentados tengan en cuenta el uso del monolito y el requerimiento de seguridad solicitado.

Forma de Entrega:

Con este primer diseño el equipo de tecnología, en acuerdo con las diferentes áreas, definió ciertas funcionalidades que se consideran importantes y de baja complejidad, adecuadas para este ciclo del desarrollo. El objetivo de su equipo es documentar, diseñar e implementar dos historias de usuario haciendo uso de un conjunto de microservicios ya implementados y los patrones de diseño vistos durante estas semanas.

Las historias de usuario seleccionadas son:

Historias de usuario

Servicios actuales

Otro equipo de desarrollo ha estado construyendo un conjunto de microservicios que responden a algunas entidades del negocio y que usted debe aprovechar para cumplir con estos requerimientos.

Las imágenes ya se encuentran en un registro de contenedores y la documentación de su funcionamiento, así como los archivos de despliegue se encuentran en el siguiente enlace.

repositorio

Se recomienda primero leer la documentación descrita en el archivo README del proyecto, realizar el despliegue de cada uno en su infraestructura y probar que su funcionamiento sea correcto.

40 puntos

Haciendo uso de la información de las historias de usuario y la descripción de los servicios ya implementados en la plataforma, junto con su equipo de trabajo usted debe realizar un documento de arquitectura donde se describen los microservicios y decisiones de diseño que solucionan ambos requerimientos.

Tenga en cuenta los siguientes lineamientos para el diseño de su solución.

• La solución debe contemplar que el usuario final de estos requerimientos, solo conocerá UN punto de acceso al sistema y por lo tanto hará UNA sola petición web por cada requerimiento, y no una secuencia. El sistema recibirá cada solicitud y se encargará de que todos los componentes trabajen juntos para completar cada objetivo.
• La solución debe contemplar una alta demanda de usuarios, que se incrementará con el tiempo.
• La solución debe contemplar que solo usuarios autenticados y autorizados pueden hacer uso de estos nuevos servicios.
• La solución debe contemplar todo lo que se encuentra implementado, tanto los microservicios como el monolito. No se deben duplicar funcionalidades.
• Para el primer requerimiento se debe contemplar que cuando no se cumple una precondición del sistema, la transacción debe hacer rollback y el sistema debe quedar consistente. No pueden quedar datos inconsistentes en el sistema como por ejemplo; la agenda ocupada con un pedido que no se pudo solicitar su pago.
• Para el segundo requerimiento se debe contemplar que los microservicios van a fallar y por lo tanto no pueden bloquear el sistema; estos se deben recuperar automáticamente. La resiliencia del sistema es un punto a evaluar en este requerimiento.

Complete las siguientes actividades:

[15 puntos] Modelo de componentes

Implementar dos diagramas de componentes de la vista funcional (uno por cada requerimiento) en el que se describen los componentes necesarios (tanto nuevos como anteriormente implementados) para cumplir con ambas historias (sea explícito en cuanto a endpoints y métodos de consumo). Adicionalmente, cada componente NUEVO debe estar listado con la siguiente información:

[15 puntos] Documentación de patrones

Documentar los patrones de diseño utilizados para la solución de cada punto.

[10 puntos] Documentación del proceso,

Por medio del diagrama de su preferencia (preferiblemente de secuencia), describa cómo será el comportamiento paso a paso de cada una de las soluciones. Este debe tener en cuenta flujos de excepción y manejo de errores.

Con respecto a la resiliencia:

Criterios de Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• Completitud funcional: Se evaluará que el diseño propuesto resuelva funcionalmente la problemática planteada en el enunciado. Deben haber componentes suficientes para cada uno de los puntos de interacción del sistema y en su conjunto deben dar soporte al caso de negocio presentado en el enunciado.
• Justificación: Se evaluará que cada decisión de diseño relacionada con los patrones y temas vistos en la semana esté presente y sea correcta.
• Efectividad: Se evaluará que el diseño presentado resuelva las necesidades no funcionales planteadas por negocio y que las decisiones de diseño tomadas cumplan con ese objetivo. En específico la resiliencia y la consistencia de la información.

Forma de Entrega:

A partir de este momento usted debe realizar la implementación de los componentes nuevos que ayudarán a cumplir con el objetivo del proyecto. Para ello usted tendrá acceso a un nuevo repositorio donde almacenará, el código, archivos de configuración y documentación necesaria para poder replicar sus pruebas en otros ambientes.

25 puntos

Basado en el diseño del entregable II, debe realizar una implementación funcional de los componentes incluidos en el diseño. Para la implementación de los componentes tenga en cuenta los siguientes lineamientos:

• Utilice un solo repositorio de GitHub para almacenar el código fuente de todos los componentes. En el curso de DevOps se verán buenas prácticas sobre la forma de almacenar y gestionar el ciclo de vida del código.
• Cada microservicio puede ser construido en python, nodejs o java. Valide con su tutor la tecnología que desea usar en el caso que no use la recomendada por el curso (flask).
• El código debe estar dividido por carpetas, donde cada carpeta es un microservicio.
• Debe haber un archivo README.md en la raíz que indique la estructura de las carpetas y como hacer el despliegue.
• En cada carpeta debe estar el código del microservicio junto con el archivo Dockerfile y el archivo .yml para el despliegue.

Criterios de Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• Completitud y exactitud respecto al diseño: Se verificará que la solución entregada contenga la implementación de las decisiones de diseño planteadas en el Entregable II.
• Solución del problema: Se verificará la correspondencia entre la solución entregada y el problema planteado en el enunciado. El código fuente entregado debe exponer endpoints y ejecutar lógica de negocio que dé soporte al proceso planteado.
• Calidad de código: Se evaluará que el código esté bien documentado y que sea fácil de leer. Trate de agregar comentarios a los archivos, funciones y definiciones que permitan entender su propósito y responsabilidad.
• Adicionales: Se entrega el archivo de postman que puede ser utilizado para probar los servicios en producción.

Forma de Entrega:

10 puntos

Debe realizar un video en el que sustente (con su voz) lo siguiente:

• Los componentes desplegados en la consola de GCP.
• Una prueba de la creación de los datos que finaliza correctamente.
• Las pruebas de creación que validen los criterios de aceptación de fallo y ver que la información es consistente al finalizar.
• Una prueba de la consulta de los datos que finaliza correctamente.
• Una prueba de la consulta simulando un fallo y cómo el servicio fallido no es bloqueante hasta que todo el sistema vuelve a estar disponible automáticamente.

El video no debe tener una duración superior a los 20 minutos.

Criterios de Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• Componentes desplegados: En el video se evidencia el despliegue de los componentes diseñados en el Entregable II. Se deben ver en las listas de recursos de la consola del proveedor.
• Prueba de funcionalidad: Se sustenta el sistema funcionando según el problema planteado en el enunciado y el diseño entregado en el entregable II. El archivo de postman con el que se exhibe y prueba la funcionalidad corresponde al entregado en el Entregable II. Se presenta al tiempo que el sistema falla y cómo gestiona los fallos.

Forma de Entrega:

Esta sección contiene la información de los cambios que se han realizado a este enunciado desde su publicación.