Diseños de bajo nivel, planes de prueba e integración continua

Básicamente un diseño a bajo nivel se refiere a especificar exactamente cómo va a funcionar cada una de las secciones que detallamos en la arquitectura del sistema, desde qué tecnologías vamos a usar, cómo se van a comunicar, TODO.
.
Para ello podemos basarnos en diagramas, lo más importante a tomar en cuenta es que esto lo podemos poner en la sección de Modelo de Datos de nuestro documento de diseño.
.
En esta clase se habla sobre creación de entidades, este es un concepto muy usado en bases de datos, y de hecho lo que se hizo en esta clase fue crear una entidad de una base de datos, recomiendo el curso de Fundamentos de Bases de Datos para profundizar en las entidades.
.
También se habló de las etapas que realizamos para hacer las pruebas, esto se conoce como TDD (Test Driven Development) que es básicamente una metodología de desarrollo basada en tests, aquí lo importante a notar son los pasos, desde la creación del usuario, mandar la solicitud y probar que todo funcione, esos son los pasos que debemos integrar en un TDD, recomiendo el Curso de Introducción a Laravel donde al final hacemos un API básico usando TDD.
.
Por último, también se habló del flujo de integración continua, Freddy habla sobre este flujo de desarrollo profesional en una clase del Curso Profesional de Git y GitHub y cómo podemos manejar ese flujo de trabajo con git, desde estar en el servidor de desarrollo, hacer un pull request al servidor de pruebas y finalmente mandarlo a producción, les recomiendo esta clase en donde se explica este flujo de desarrollo ^^

Si hay dudas al momento de elegir una tecnologia, entonces habria que hacer unas pruebas de concepto para ver cual se adapta mejor a el problema, para luego no tener problemas de compatibilidad entre las tecnologias elegidas. Creo que ese seria un paso importante tambien, no siempre lo sabes todo como para dar una solucion inmediata.

En el documento de bajo nivel se detalla el COMO se desarrollarán los servicios.
Para los que quieran saber un poco más de TDD, es una metodología de desarrollo que se basa en primero escribir las pruebas y posteriormente escribir el código de la funcionalidad, hasta lograr que pase el test.
Si quieren desarrollar un proyecto usando esta metodología les recomiendo los siguientes cursos.
- Curso de Ruby
- Curso Intermedio de Ruby on Rails
- Curso de Creacion de APIs con Ruby on Rails

En cuanto la integración continua, o CI les recomiendo el curso del profe David Aroesti sobre DevOps con GitLab, explica los conceptos de CI/CD y cómo podemos llevarlos a cabo en GitLab.
Curso de DevOps con GitLab

Cuando vaya iterando y las entidades, herramientas de CI, etc. van cambiando se debe ir modificando este documento o solo es un documento inicial?

Todo un Pipeline si trabajas en una buena empresa.

Creo que diseñar esto puede llegar a construir este tipo de diseños en nuestros proyectos los convierte en unos sistemas de muy alta calidad y pensar en tiempos de respuesta y optimizacion para el backend es clave para servicios de cietos de miles y millones de peticiones, ademas que utilice cloud computing es algo muy importante porque da la confianza de que el servicio va a estar 24/7 las lambdas o funciones serverless son impresionates!!!

Testing = Quality Assurance

Para estos diagramas recomiendo utilizar C4 Model, con esto se puede visualizar toda la arquitectura en diferentes niveles de especificación, desde el contexto del sistema hasta un diagrama de componentes internos de un microservicio y/o contenedor.