Diseño de Sistemas: Documentación de Bajo Nivel y Pruebas

Contenido del curso

Introducción a conceptos

Arquitectura y planeación

Desarrollo e implementación

Challenges

Conclusión

25
Preparación Profesional para Desarrolladores Back End Avanzados
05:29 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0015:23

Diseño de Sistemas: Documentación de Bajo Nivel y Pruebas

Curso Práctico de Arquitectura Backend

Clase 12 de 25

Clase 12 / 25

Comentarios (13)13 comentarios

RUBÉN HERNÁNDEZ PUERTA

Hace 6 años

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

Dante Calderón

Hace 6 años

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.

Fernando José Aguilar Rivas

Hace 6 años

Excelente el punto que acabas de plantear. Pero sin embargo una solución prudente es dividir así como ya lo dijo el docente en el curso dividir en servicios y hacer la comunicación por medio de API's así se evita el conflicto entre diferentes tecnologías.

Junior Usca Huacasi

Hace 6 años

La selección de lenguajes de programación depende más del equipo de programadores encargado, puede ser cualquier lenguaje y luego escalar el microservicio si es necesario.

Dante Calderón

Hace 6 años

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

Alejandro Picado Brenes

Hace 6 años

Hola Dante, yo lo que normalmente hago son mínimo 2 actualizaciones de base a un documento de arquitectura o diseño:

La elaboración inicial del documento desarrollando los apartados que menciona el profesor con sus revisiones.
Al final luego de una iteración o desarrollo, si lo amerita realizo algunas actualizaciones para dejar plasmados cambios importantes.

Va depende mucho además de la metodología de trabajo y de la evolución que vaya teniendo el diseño de la implementación final comparado al inicial y qué tanto se necesite consultar el documento, lo importante es que ojalá al final haya logrado abarcar los puntos necesarios para solucionar la necesidad y quede escrito para su futura referencia.

Carlos Fernando Aguilar González

Hace 5 años

Jesús Henríquez

Hace 5 años

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.

Claudio Jesus Vázquez Villanueva

Hace 6 años

Todo un Pipeline si trabajas en una buena empresa.

Cesar Augusto Silva Ruiz

Hace 3 años

Bueno día.

En días pasados en una charla de arquitectura, se referían a los diseños como Diseño estratégico y Diseño táctico.

Diseño estratégico: Define los objetivos generales del sistema, como los requisitos de rendimiento, escalabilidad y seguridad.

Diseño táctico: Implementa los detalles del sistema, como la elección de las tecnologías y los patrones de diseño.

En otras palabras, el diseño estratégico se centra en lo que el sistema debe hacer, mientras que el diseño táctico se centra en cómo el sistema lo hará.

¿Es correcto afirmar que es lo mismo que explica el profe cuando se refiere a diseño de alto y bajo nivel?

Royer Guerrero Pinilla

Hace 6 años

Una pregunta respecto a testing

Cuando hago testing a los endpoints de cualquier API por testing me refiero a proabar si el POST, GET, PUT, PATCH o DELETE funcionan como debe o probar filtros son prubas unitarias?

William Schnaider Torres Bermon

Hace 3 años

Tenemos tres casos: . Caso 1 (tomaré como referencia el modelo MVC para simplificar): Estas probando tus propios endpoints mockeando la capa inferior de los controladores (es decir, los servicios o modelos). En este caso estas haciendo pruebas unitarias de los controladores. . Caso 2: Estas probando tus propios endpoints haciendo uso completo de la aplicación. En este caso estas haciendo pruebas de integración, ya que estas comprobando que cada uno de los componentes asociados a ese endpoint, funcionen adecuadamente al momento de manejar una petición. Estas pruebas las puedes hacer dentro del mismo proyecto o usando alguna herramienta adicional (SoapUI, Jmeter, Postman, Insomnia, K6, etc). . Caso 3: Estas probando los endpoints (API) de un tercero haciendo uso del sistema real o mockeando las respuestas. En este caso estas haciendo pruebas de integración, ya que estas comprobando como se comportan tus componentes al interactuar con la API del tercero.

Royer Guerrero Pinilla

Hace 6 años

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!!!

john fredy quimbaya orozco

Hace 2 años

una nomenclatura correcta con la que he tenido la oportunidad de trabajar es la c4, esmuy entendible y llega a todas las partes desde el diagrama de contexto al diagrama por componentes.

Nicoll Idaly Angulo Mejia

Hace 3 meses

Buen comentario

Vi este vídeo y me gustó un montón

José Luis Tirella

Hace 6 meses

Perdón, solo quiero dejar una crtitica constructiva, vamos por el capitulo 12 y considero que se habla mucho y no hay ejemplos concretos de escenarios reales. Podrían darle una vuelta de rosca a los temas que exponen.

Irving Juárez

Hace 2 años

Sigo sin entender porque se usa dynamo para escribir y aurora para leer. Aunque creo que es más bien por fines didacticos, en mi opinión, yo creo que todo deberia ser hecho con SQL, en este caso Aurora (aunque Aurora no seria mi primera opción ya que es muy cara para un MVP, que es nuestro caso), por la simple razón de que los datos de las reseñas son datos estructurados y consistentes. No es como que una reseña va a tener datos que otra reseña no, todas tienen los mismos datos. Además de que AuroraDB ya ofrece read replicas por defecto, para ya no tener que estar configurando una base de datos de lectura, de hecho creo que ofrece 7 bases de datos de lectura como inicio (les digo que es mucho para un MVP)

Gilberto Pérez Garrido

Hace 4 años

Testing = Quality Assurance

Recursos

¿Qué es el diseño de bajo nivel y su importancia en el desarrollo de software?

El diseño de bajo nivel es un aspecto crucial del desarrollo de software que se enfoca en el detalle específico y técnico de un sistema. Mientras que el diseño de alto nivel abarca aspectos generales y la arquitectura del sistema, el diseño de bajo nivel va un paso más allá, proporcionando especificaciones detalladas sobre cómo funcionará cada parte del sistema. Este diseño no solo define cómo implementaremos una base de datos MySQL, por ejemplo, sino que también incluye consideraciones sobre las tecnologías y frameworks que usaremos. Además, permite la integración de múltiples lenguajes de programación para diferentes servicios, otorgando flexibilidad y un control significativo a los desarrolladores.

¿Cómo se estructura un documento de diseño de bajo nivel?

Un documento de diseño de bajo nivel se enfoca en detalles más técnicos del sistema, centrándose en la arquitectura y el modelado de datos. A diferencia del diseño de alto nivel, aquí nos enfocamos en partes específicas del sistema con un mayor detalle técnico. Por ejemplo, podemos centrarnos únicamente en el servicio de escritura, que incluye una función serverless para gestionar el proceso de escritura y almacenar en una base de datos no relacional. Este documento también puede incluir:

Una descripción detallada de cómo se comunican los servicios de escritura con bases de datos como DynamoDB y cómo un servicio de procesamiento inserta datos en bases de datos relacionales como Aurora.
Diagramas de flujo que reflejan cómo se transportan y transforman datos entre servicios y bases de datos.
Especificaciones sobre los motores de bases de datos y las tecnologías seleccionadas para cada componente.

¿Cómo se define y estructura el modelo de datos?

Para definir el modelo de datos en un documento de diseño de bajo nivel, es esencial elaborar las entidades que formarán parte del sistema. Estas entidades representan objetos concretos dentro del modelo de datos, como una reseña, la cual puede incluir entradas como título, contenido y una lista de imágenes. Cada componente se convierte en un "objeto" que puede representarse mediante diferentes formatos, como JSON o tablas, dependiendo de las necesidades del sistema. Además, es crucial considerar asociaciones entre entidades, como aquellas entre una cámara y sus modelos o marcas.

Ejemplo de representación de datos en JSON:

{
  "id": "123456",
  "titulo": "Reseña de la Cámara XYZ",
  "contenido": "Esta es una excelente cámara por su...",
  "imagenes": [
    "imagen1.jpg",
    "imagen2.jpg"
  ],
  "camara": {
    "modelo": "XYZ",
    "marca": "Canon"
  }
}

Este ejemplo muestra cómo puede estructurarse un objeto de reseña en un sistema que trabaje con datos representados en JSON.

¿Cuál es el papel del plan de pruebas e integración continua?

El plan de pruebas y la integración continua son componentes vitales en un documento de diseño de bajo nivel. Estas secciones garantizan que el sistema sea probado de manera exhaustiva y que cualquier nueva funcionalidad o cambio se integre sin problemas en el entorno de producción. Algunas acciones recomendadas para el plan de pruebas incluyen:

Pruebas End-to-End:
- Registrar usuarios, crear reseñas y simular que los visitantes pueden leerlas.
- Asegurar que el flujo de trabajo funcione correctamente de principio a fin.
Diagramación de Integración Continua:
- Visualizar el flujo de trabajo desde el desarrollo hasta la producción.
- Establecer entornos de desarrollo, pruebas y producción para validar los cambios antes de su lanzamiento.

Este enfoque asegura que cualquier característica del sistema pase por rigurosas validaciones, asegurando su correcto funcionamiento antes de que llegue al usuario final. Además, define un ciclo de desarrollo claro donde solo el código que pasa las pruebas de calidad es impulsado hacia la producción, minimizando posibles errores.

El diseño de bajo nivel es clave para asegurar que cada parte de un sistema funcione como se espera, proporcionando una base sólida para un desarrollo limpio y eficiente. Estás en el camino correcto para dominar este aspecto esencial del desarrollo de software. ¡Sigue adelante!

Resumen

¿Qué es el diseño de bajo nivel y su importancia en el desarrollo de software?

¿Cómo se estructura un documento de diseño de bajo nivel?

Una descripción detallada de cómo se comunican los servicios de escritura con bases de datos como DynamoDB y cómo un servicio de procesamiento inserta datos en bases de datos relacionales como Aurora.
Diagramas de flujo que reflejan cómo se transportan y transforman datos entre servicios y bases de datos.
Especificaciones sobre los motores de bases de datos y las tecnologías seleccionadas para cada componente.

¿Cómo se define y estructura el modelo de datos?

Ejemplo de representación de datos en JSON:

{
  "id": "123456",
  "titulo": "Reseña de la Cámara XYZ",
  "contenido": "Esta es una excelente cámara por su...",
  "imagenes": [
    "imagen1.jpg",
    "imagen2.jpg"
  ],
  "camara": {
    "modelo": "XYZ",
    "marca": "Canon"
  }
}

Este ejemplo muestra cómo puede estructurarse un objeto de reseña en un sistema que trabaje con datos representados en JSON.

¿Cuál es el papel del plan de pruebas e integración continua?

Pruebas End-to-End:
- Registrar usuarios, crear reseñas y simular que los visitantes pueden leerlas.
- Asegurar que el flujo de trabajo funcione correctamente de principio a fin.
Diagramación de Integración Continua:
- Visualizar el flujo de trabajo desde el desarrollo hasta la producción.
- Establecer entornos de desarrollo, pruebas y producción para validar los cambios antes de su lanzamiento.

Introducción a conceptos

Arquitectura de Backend: Diseño e Implementación de Sistemas Avanzados

Conceptos Fundamentales de Back End en Arquitectura Web

Sistemas Monolíticos vs. Distribuidos en Arquitectura Backend

Componentes de un Sistema Backend Distribuido

Conexión de Componentes Backend mediante APIs

Diseño e Implementación de Sistemas Backend Prácticos

Arquitectura y planeación

Definición de Requerimientos de Negocio para Desarrolladores Backend

Creación de Documentos de Diseño de Software

Creación de Documentos de Diseño en Markdown para Proyectos de Software

Revisión Efectiva de Documentos de Diseño en Equipo

Diseño de Arquitectura de Sistemas Distribuidos

Diseño de Sistemas: Documentación de Bajo Nivel y Pruebas

Planificación de Integración Continua y Rollout de Software

Definición y aplicación del concepto "Code Complete" en proyectos software

Decisiones en Diseño de Sistemas Basados en Requerimientos del Negocio

Desarrollo e implementación

Desarrollo e Implementación de Sistemas Backend

Diseño de Entidades para Reseñas de Cámaras y Productos

Diseño e Implementación de Interfaces en C para Productos y Reseñas

Desarrollo de Pruebas Unitarias con TDD en C#

Implementación de pruebas unitarias con TDD en proyectos de software

Desarrollo de un Sistema de Reseñas en Azure

Challenges

Diseño de Servicios de Lectura Escalables y Stateless

Diseño e Implementación de un Servicio de Autenticación

Escalabilidad: Implementación de Throttling y Retry Policy

Conclusión

Preparación Profesional para Desarrolladores Back End Avanzados

Diseño de Sistemas: Documentación de Bajo Nivel y Pruebas

Progreso del curso

Introducción a conceptos

Arquitectura y planeación

Desarrollo e implementación

Challenges

Conclusión

Recursos

Recursos