El objetivo de este curso es fomentar las buenas prácticas de desarrollo backend mediante unas bases sólidas necesarias previas a codificar. Comenzaremos por un breve repaso de temas como: Protocolo HTTP, Arquitectura de Software (Layered vs Modular), Diagramas de flujo, de entidad relación, el concepto de DTO (Data Transfer Object) y, por último, la implementación a nivel código de todos estos conceptos.

Importante: Los conceptos se explicaran primero mediante una analogia con fin de que aquellas personas interesadas en la rama de desarrollo backend tengan un acercamiento totalmente amigable. Finalizando con una breve explicacion tecnica para que las mismas, se adecuen a un lenguaje mas formalizado.

Protocolo HTTP

Imagina que estás en un restaurante y quieres pedir algo de comida. Tú eres el cliente y el restaurante es el servidor web. Quieres hacer un pedido y recibir la comida en respuesta.

Cuando quieres hacer un pedido, levantas la mano y llamas la atención del mesero. Esto sería como enviar una solicitud HTTP al servidor web.

Luego, le dices al mesero lo que quieres comer. Puedes pedir una hamburguesa, una ensalada o cualquier otra cosa. Esta es tu solicitud específica al servidor web.

El mesero lleva tu pedido a la cocina y espera a que los chefs preparen la comida. La cocina es como el servidor web que procesa tu solicitud y obtiene la información o realiza la acción solicitada.

Finalmente, el mesero regresa con tu comida y te la entrega. Esto es como la respuesta del servidor web que envía la información solicitada de vuelta a tu dispositivo para que puedas verla en tu navegador.

En resumen, HTTP es como pedir comida en un restaurante. Haces una solicitud al servidor web (levantando la mano), le dices lo que quieres (tu pedido) y el servidor procesa tu solicitud y te envía la respuesta (la comida) de vuelta.

Siendo un poco mas técnicos, podemos decir que el protocolo HTTP es un conjunto de reglas que define cómo los dispositivos de la web se comunican entre sí. Permite que los clientes (como los navegadores web) soliciten recursos y que los servidores web les respondan con la información solicitada. Ademas, este protocolo (o Protocolo de Transferencia de Hipertexto en español) es parte de un conjunto de cosas que hace posible que se pueda navegar en internet.

Continuando con la analogia del restaurante, los métodos HTTP serían como las diferentes formas en las que puedes interactuar con el personal del lugar para solicitar lo que necesitas. Cada método correspondería a una acción específica. Por ejemplo, podrías usar un método para pedir un plato nuevo (agregar información), otro método para solicitar la cuenta (obtener información), o incluso un método para hacer una reserva en el restaurante (realizar una acción). De esta manera, los métodos HTTP son como las opciones que tienes para comunicarte y realizar acciones en el mundo digital de la web, al igual que en un restaurante interactúas con el personal utilizando diferentes enfoques según tus necesidades.

Arquitectura de Software (Layered vs Modular)

Imaginemos que estás diseñando un restaurante y te encuentras frente a dos opciones para organizar su estructura: la arquitectura en capas y la arquitectura modular.

La arquitectura en capas sería como dividir el restaurante en diferentes áreas bien definidas, como la cocina, el comedor y el área de servicio. Cada área tiene funciones específicas y se encarga de tareas particulares. Por ejemplo, en la cocina se preparan los alimentos, en el comedor se atiende a los clientes y en el área de servicio se realizan labores de limpieza y mantenimiento. Esta división en capas permite una clara separación de responsabilidades y facilita la gestión de cada área de forma individual.

Por otro lado, la arquitectura modular sería como diseñar el restaurante con módulos independientes y reutilizables. Cada módulo puede ser una sección del restaurante, como un bar, un salón privado o una terraza. Estos módulos se pueden combinar y adaptar de manera flexible según las necesidades del restaurante. Por ejemplo, puedes agregar o quitar salones privados según la demanda o cambiar la ubicación del bar sin afectar el resto del restaurante. La arquitectura modular permite una mayor flexibilidad y adaptabilidad en el diseño del restaurante.

En resumen, al igual que en la arquitectura de software, en el diseño de un restaurante puedes optar por una estructura en capas para una separación clara de funciones o por una estructura modular para una mayor flexibilidad y adaptabilidad. La elección depende de los objetivos y necesidades específicas del restaurante que estés creando.

Este mapa conceptual, es aplicable a ambas arquitecturas

Layered Architecture (4)

src
│   index.ts        # App entry point
└───controllers     # route controllers for all the endpoints of the app
└───config          # Environment variables and configuration related stuff
└───models          # Database models
└───repositories    # Custom queries to database
└───services        # All the business logic is here
└───routes          # Express.js entry points to controllers

Modular Architecture

src
│   index.ts        # App entry point
└── config      
└── products 
        └── controller
        └── service
        └── model
        └── repository
        └── route

Ver el articulo de Stairway to Heaven: Saliendo de Folder Hell.

Continuando con nuestra analogia del restaurante, imaginemos que debemos crear una solucion para mejorar un proceso que hasta el momento se registraba de forma manual a papel, sustituyendolo por un sistema efectivo. Para comenzar, partiremos desarrollando una accion basica que se vive diariamente en el local: El pedido del cliente. Tambien, lo registraremos como plus.

Esto es a modo de ejemplo, para un proyecto real, se debe ser mas cuidadoso.

Para comenzar, tenemos dos opciones: codear desde el momento cero, o aun mejor, partir desde un diagrama que nos servira para sentar las bases de como sera la logica de negocios posteriormente en nuestro codigo.

Diagrama de flujo

Tener un diagrama de flujo, nos permite visualizar como se comportara nuestro restaurante ante dos situaciones, registrar un cliente en nuestra base de datos, o en el momento que dicho cliente solicita un plato. A simple vista, estamos viendo dos "cosas" notablemente distintas: un cliente, un plato. Y una tercera que no esta tan a la vista, pero es la razon para que las dos anteriores sean posibles, el restaurante.

A estas cosas, se les conoce como Entidad, las cuales son utilizadas para modelar y representar estos elementos del mundo real en el código. Por ejemplo, si estás desarrollando una aplicación de gestión de usuarios, podrías tener una entidad llamada "Usuario" que contendría atributos como nombre, dirección de correo electrónico, contraseña, etc.

Diagrama entidad relación

Una vez se definen las entidades de nuestro negocio, se pasa a crear un diagrama de entidad relación. Este, permitira conocer como se relaciona una entidad con otras.

     +---------------------+        +------------------+
     |     Restaurante     |        |      Cliente     |
     +---------------------+        +------------------+
     |      restaurante_id |<------o|    cliente_id    |
     |        nombre       |        |      nombre      |
     |      direccion      |        |     direccion    |
     +---------------------+        +------------------+
                 |                            |
                 |                            |
                 |                            |
          +------+------+                     
          |    Platos   |
          +-------------+
          |   plato_id  |
          |   nombre    |
          |   precio    |
          +-------------+
                 |
                 |
          +------+------+
          |   Pedido    |
          +-------------+
          |  pedido_id  |
          |  cliente_id |
          |  plato_id   |
          +-------------+

En un principio, si observamos nuestro diagrama de flujo, no vemos la entidad "pedido" sin embargo, es comun crear una tabla extra, para poder relacionar una entidad con otra en caso de no existir relacion directa. En este caso, un cliente realiza un pedido, en el pedido puede tener x plato.

Una entidad, a nivel base de datos, se representa en una tabla.

Por ultimo, recordar que dichas entidades jamas se exponen directamente a la capa de presentación, en su lugar, de cara al cliente se utiliza un objeto de transferencia de datos... Lo que permite cierta flexibilidad, entre otras bondades.

Data Transfer Object

Imaginemos que estás en un restaurante como cliente y deseas realizar un pedido para llevar. Te comunicas con el personal del restaurante y les das los detalles de tu pedido, como los platos y las cantidades requeridas. Ahora, el personal necesita transmitir esa información al equipo de cocina de una manera clara y estructurada para que puedan preparar tu pedido correctamente.

Aquí es donde entra en juego el concepto de DTO (Data Transfer Object). Podemos considerar el DTO como una bandeja o bandeja de pedidos que recopila y transporta la información necesaria desde el cliente hasta el equipo de cocina del restaurante. En este caso, el DTO sería una representación estructurada y simplificada de tu pedido, que contiene los detalles necesarios como los nombres de los platos y las cantidades requeridas.

El DTO actúa como un contenedor de datos que permite transferir información de forma eficiente y coherente entre diferentes componentes o capas de la aplicación, como la capa de presentación y la capa de servicios. En lugar de enviar todos los detalles del objeto original, se utiliza un DTO para transmitir solo la información necesaria y relevante para una operación específica.

En resumen, un DTO en el contexto de un restaurante sería como una bandeja o bandeja de pedidos que contiene una representación estructurada y simplificada de la información necesaria para transmitir un pedido desde el cliente al equipo de cocina. Del mismo modo, en el desarrollo de software, un DTO es un contenedor de datos utilizado para transferir información de forma eficiente entre diferentes componentes o capas de una aplicación.

En el proximo articulo, se aplicaran todos estos conceptos de forma practica en SpringBoot, creandolo desde 0 con Sprint Initializr con las dependencias necesarias, instalacion de dependencias extras como ModelMapper para facilitar el uso de DTO's, asi como la configuracion correcta de nuestra base de datos mediante un archivo de extension YML, testeando nuestra implementacion con MySQL Workbench, Postman, y haciendo uso de scripts SQL para cargar datos.

Despedida

Espero se hayan entretenido, les guste y estén esperando el próximo.