Después de recorrer los fundamentos de TDD y construir la entidad de cámara paso a paso, llega el momento de escalar el proyecto. Aquí se explica la arquitectura que sirve como punto de partida, el caso de uso que el instructor resuelve como referencia y los retos que cada estudiante debe abordar para completar el sistema de reseñas de cámaras.
¿Qué caso de uso resuelve el instructor como referencia?
El instructor presenta un diagrama de arquitectura diseñado en diagrams.net [01:15], una herramienta de diseño mencionada en módulos anteriores. El flujo comienza en el front end, donde un usuario registrado publica una reseña. Esa acción dispara una solicitud que atraviesa varios componentes en la nube.
- El cliente envía un HTTP POST hacia un servicio de API Management en Azure [01:45].
- API Management recibe la petición y la redirige a una función de Azure Functions, un servicio serverless conocido como Function as a Service [02:05].
- Azure Functions ejecuta la lógica necesaria e inserta la información en Cosmos DB, una base de datos no relacional de Azure [02:25].
Para quienes trabajan con AWS, las equivalencias son directas: Azure Functions corresponde a AWS Lambda, y Cosmos DB se equipara con DynamoDB [02:15]. Este mapeo permite adaptar la solución a cualquier proveedor de nube sin cambiar la lógica de negocio.
¿Por qué esta solución no está completa?
El instructor aclara que su implementación cubre únicamente el servicio de escritura: crear una reseña y almacenarla. El objetivo es ofrecer un modelo de referencia — no la solución final — para que cada estudiante lo estudie, lo compare con su propio código y construya a partir de ahí [02:40].
¿Qué significa usar un servicio serverless en este contexto?
Un servicio serverless como Azure Functions permite ejecutar código sin aprovisionar ni administrar servidores. Se paga solo por las ejecuciones realizadas, lo que resulta ideal para operaciones puntuales como procesar un POST de reseña y guardarla en la base de datos.
¿Cuál es el reto del estudiante para completar el proyecto?
El trabajo pendiente gira alrededor de diseñar e implementar las piezas que faltan. El instructor esboza un ejemplo con un servicio de lectura que se conecta a API Management mediante un HTTP GET (GET /review) [03:15]. Este servicio recupera las reseñas almacenadas y las devuelve al cliente.
- Elegir la base de datos del servicio de lectura: puede ser MySQL, MongoDB, PostgreSQL o cualquier otra opción [03:35].
- Considerar un servicio de caché intermedio para mejorar el rendimiento de las consultas [03:55].
- Diseñar un servicio de migración que traslade datos desde Cosmos DB hacia la base de datos de lectura [04:10].
Esta separación entre escritura y lectura refleja un patrón arquitectónico conocido como CQRS (Command Query Responsibility Segregation), donde los flujos de escritura y lectura se manejan de forma independiente.
¿Cómo abordar el diseño desde cero?
El instructor recomienda documentar cada decisión en un documento de diseño y compartirlo con compañeros para recibir feedback [04:30]. Buscar retroalimentación temprana permite detectar mejoras antes de invertir tiempo en código.
- Definir el diagrama de arquitectura completo.
- Especificar cómo se comunican los servicios entre sí.
- Justificar la elección de cada tecnología.
¿Qué recursos y retos acompañan al proyecto?
En cada clase subsecuente se comparten challenges específicos [05:00] que indican exactamente qué servicio construir y qué funcionalidad implementar. Estos retos están alineados con los requerimientos del negocio y van guiando el desarrollo progresivo del sistema.
- Apoyarse en los recursos adjuntos de cada clase.
- Seguir la metodología TDD practicada con la entidad de cámara.
- Cumplir con todos los requerimientos planteados a lo largo del curso.
El camino está trazado: un caso de uso resuelto como base, herramientas claras y retos progresivos. ¿Qué base de datos elegirías para tu servicio de lectura y por qué? Comparte tu decisión con la comunidad.
