cuando se maneja todo el proyecto en ingles se puede usar el siguiente estándar de nombrado. Usando como ejemplo la entidad Product:
ProductDTO para objetos de dominio
Product para las entidades
Antes de empezar
¿Qué es y qué usaremos de Spring?
¿Java sigue siendo gratuito?
Instalación de ambiente de desarrollo: Windows
Instalación de ambiente de desarrollo: Linux Ubuntu
Instalación de ambiente de desarrollo: macOS
Introducción a Spring boot
Creando aplicaciones autocontenidas con Spring Initializr
Hola mundo con Spring Boot
Configurar Spring Boot
Crear la estructura del proyecto
Spring Data
¿Qué es JPA?
Conocer qué es Spring Data
Conectar la base de datos a nuestra aplicación
Mapear las tablas como clases
Crear Entity cuando su clave primaria es compuesta
Mapear relaciones entre clases
Usar la interface CrudRepository
Query Methods
Construyendo nuestra API
Implementar la anotación @Repository
¿Qué es el patrón Data Mapper y qué resuelve?
Orientar nuestra API al dominio con MapStruct
Orientar nuestro repositorio a términos del dominio
Inyección de dependencias
Implementar la anotación @Service
Implementar la anotación @RestController
Exponer nuestra API
Mejorando nuestra API
Controlar las respuestas HTTP
Crear el dominio de compras
Mapear el dominio de compras
Crear el repositorio de compras
Probando nuestros servicios de compras
Documentar nuestra API con Swagger
Despliegue de nuestra aplicación
Desplegar nuestra API desde la ventana de comandos
Desplegar nuestra base de datos con Heroku
Desplegar nuestra API con Heroku
Conclusiones y despedida del curso
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Recursos
¿Cómo orientar el repositorio de productos al dominio?
Para desarrollar software sólido y flexible, es fundamental orientar los repositorios al dominio. Esta práctica desvincula la lógica de negocio de la infraestructura de almacenamiento, adaptándose a cambios futuros, como migraciones a distintas bases de datos. En este caso, reemplazamos una estructura rígida y dependiente de una tabla SQL particular por una forma más abstracta y orientada al dominio. Empecemos paso a paso.
¿Qué es la implementación de interfaces en repositorios?
Para comenzar, debemos asegurarnos de que nuestro productRepositorio implemente la interfaz que diseñamos previamente. Esta interfaz define los métodos necesarios que nuestro dominio requiere, como recuperar todos los productos o salvar un nuevo producto.
public class ProductRepositorioImpl implements ProductRepositorio {
// Mensaje de advertencia debido a métodos no implementados
// Implementación pendiente de métodos obligatorios de la interfaz
}
¿Cómo usar un mapper para transformar entidades?
El siguiente paso es la utilización de un ProductMapper que facilite la conversión de producto a Product. Esta clase actúa como intermediario, simplificando la transformación de las entidades de la base de datos al objeto del dominio.
- Uso del método
getAll: Aquí obtenemos productos de un repositorio y los transformamos a través del mapper.
@Override
public List<Product> getAll() {
List<Producto> productos = cruRepositorioy.findAll();
return maper.toProducts(productos); // Transformamos la lista
}
¿Cómo trabajar con Optional para consultas específicas?
La clase Optional de Java nos ayuda a manejar valores que podrían ser nulos de manera segura y eficiente. Implementamos métodos como getByCategory y getProductosEscasos haciendo uso de esta característica.
- Consulta por categoría:
@Override
public Optional<List<Product>> getByCategory(int categoriaId) {
List<Producto> productos = productRepositorio.findByIdCategoriaOrderByNombreAsc(categoriaId);
return Optional.of(maper.toProducts(productos)); // Conversión y empaque en Optional
}
¿Cómo manejar el guardado y eliminación de productos?
Los procesos de guardar y eliminar productos también se simplifican al orientarnos al dominio. Aquí, el mapeo inverso se hace de Product a producto antes de persistir los cambios.
- Guardar un producto:
@Override
public Product save(Product product) {
Producto producto = maper.toProducto(product); // Conversión inversa
Producto savedProducto = productRepositorio.save(producto);
return maper.toProduct(savedProducto);
}
- Eliminar un producto:
La eliminación es directa dado que no requiere una conversión previa al no retornar un resultado.
¿Por qué es esencial orientar el repositorio al dominio?
Adaptar un repositorio al dominio aporta gran flexibilidad al proyecto. Flexibilidad significa poder cambiar la base de datos subyacente sin modificar la lógica ni el comportamiento de la aplicación. Por ejemplo, si migramos de SQL a MongoDB, el diseño ya anticipará tal cambio, permitiendo una transición suave con mínimos ajustes.
La orientación al dominio es clave en el desarrollo de software moderno y escalable. Aprender a integrar conceptos como mapeo y uso de Optional fortalece las habilidades de diseño, proporcionando un código más limpio y adaptable. Continúa explorando y desarrollando tus habilidades de programación, ¡el mundo del desarrollo siempre ofrece algo nuevo por descubrir!
Aportes 50
Preguntas 23
Ordenar por:
Una de las clases quizás mas densas en cuestion de la cantidad de clases, metodos y funciones a las que toca echarles una repasada. Pero es cuestion de ver una y otra vez el video y aprovechar esta explicacion magnifica para retomar el hilo del proyecto y aprender cosas importantes
yo ya se programar con java , python , javascript. he hecho aplicaciones con nodejs express ,pero ver este curso me hace sentir un principiante. asi que a esto se referia mi profe de la universidad de que con java se hace ingeniera de software de verdad.
Me parece que el profe debió hacer un repaso por el flujo de datos entre las diferentes capas, pues se vuelve un poco confuso seguirle el paso sin entender como interactuanentre si.
En mi opinión la estrategia de nombrar a las clases en español e ingles estuvo bien, porque de esa manera puede entender la forma como se utiliza MapStruct y conocer el potencial de la misma, para evitar el acoplamiento del código a una base de datos puntual y enfocar el código al dominio. Excelente explicación
Por ejemplo, en el caso del código de barras, como no tenemos acceso a este desde la API, si queremos agregarlo programáticamente, sería algo como:
@Override
public Product save(Product product) {
Producto producto = mapper.toProducto(product);
producto.setCodigoBarras("uncodigo");
// Aqui se guarda el producto con el codigo de barras
// pero luego del hacer el mapping el Product que se retorna ya no tiene el atributo codigoBarras (barCode)
return mapper.toProduct(productoCrudRepository.save(producto));
}
Sería algo así?
Resumen de que se intenta hacer:
Al orientar nuestro repositorio a términos del dominio, lo que se quiere conseguir es conectar los métodos que tenemos en el repositorio, a el dominio para que así todo funcione en términos del dominio y no de la base que está conectada directamente con la DB.
En mi opinión es importante escribir el proyecto en cualquier otro idioma diferente al que estamos acostumbrado, como lo hace el profesor porque en la vida real te encuentras con una sopa de código y esto que nos enseña nos hace ser mas ágiles para codificar o o corregir a futuro.
Felicito al 1000% al profesor, es otro de los que han explicado super bien los cursos que he tomado aqui en Platzi 😉
Un aporte en el uso de la lambda:
Mientras lo que reciba algún método coincide en el orden y tipos de los argumentos de la lambda, el método se puede pasar a referencia.
Es decir que esto:
return products.map(productDataList -> productMapper.toProducts(productDataList));
Se reduciría a esto:
return products.map(productMapper::toProducts);
Esta clase ya roza lo confuso, porque es muy necesaria una explicación gráfica para representar este punto del flujo de la arquitectura, y evitar confusiones con las estructuras mentales que forzamos para entender esta clase.
Recién empiezo con JAVA y este curso está brutal, el entender como concepto la arquitectua por capas orientadas al dominio quitó muchas confusiones que hasta esta clase tenía. Por ello una buena clase con sus comentarios es la siguiente: https://platzi.com/clases/1248-pro-arquitectura/10419-patrones-diseno-orientado-al-dominio/
Sólo la punta del iceberg, a seguirle dando!!!
“En la clase anterior, observamos como funciona Mapper Struct”. Yo la verdad ni idea de lo que estoy haciendo, parece mas un tutorial que un curso!!
Lo unico que he visto que funciona es la url.
Ahora cuando ejecute el programa, una velita y encomendacion a Diosito.
Está genial el curso, uno de los mejores que he hecho. Aunque el ejemplo quizás no sea tan preciso y redunda mucho el código.
Es el primer curso que hago en Platzi, creo que era adecuado graficar correctamente la arquitectura en diagramas, explicar el flujo.
Que confuso se volvio este curso
Si a alguno de ustedes les está dando problemas al hacer build al proyecto con un error como
No property named “<attribute>” exists in source parameter(s)
asegúrense de tener construidos en la clases los getters para todos los atributos. Si no es así, el MapStruct no puede realizar el mapeo de forma adecuada.
Más información en la documentación de MapStruct
Ya me perdí, empezaré de nuevo el proyecto porque aqui tiene código que no vi donde lo agregó en la clase ProductRepository.java de la carpeta persistence 😦
1.- Cual es la diferencia entre una lista normal y una lista optional?
2.- si la bd esta en ingles y todo esta en ingles… ya no es necesario usar MapStruct ?
3.- Porque Optional.of?
Gracias de antemano
Ahora sí se enredo esta vaina… 😦
Hace mucho que perdió el sentido que era hacer mas simples las cosas y escribir menos código, además de que este es mas difícil de leer.
Una clase y un tema que resulta tener un grado de complejidad
El Patrón de Dominio es un poco complejo, ademas los nombres de los campos suelen ser confusos al estar en ingles y español. Hubiera optado por usar el Patron de transferencia de objetos que creo que es mas simple.
Tan bien que iba las clases anteriores, seguimos para adelante!
Lo que se hace aca es tomar la Interfaz ProductRepository e implementarla en la calse ProductRepository, como se implementa , ahi que escibir los diferentes metodos de la interfaz.
que buenas clases la verdad, hasta ahora he aprendido cosas que no conocía de spring. Esta clase en particular al principio fue un poco complicada, pero logré hacerlo solo y aprendí muchas cosas nuevas.
no entiendo muy bien el uso de @Override en ProductoRepository.java fuera del dominio
Aquí me perdí profe, ya no te entendí nada 😦
Esta es la clase en la que te pierdo jaja
1. No entiendo porque se hacen primero todos esos metodos y despues los borran
2. me siento perdido
Creo que empezaré de nuevo, no tengo el código de la clase ProductRepository de persistence como lo tiene el profe, no veo donde se perdió ese código. 😦
Todas las clases deben estar orientadas al dominio?
Se que no es el tema, pero agradecería una breve explicación del método map de Optional. En que momento se declaro “prods”? De donde viene su valor?
Excelente manejo de los optionals y lambdas de java 8
PORQUE USAR MAP STRUCT
Recomendación para quien vea esta clase y le cause confusion.
Es repetirla de nuevo, traten de tener los nombres de las propiedades y metodos iguales como indica en las clases anteriores para que tomen el hilo.
casi me quedo calvo en esta clase jaja, tuve que verla varias veces :p
Usar `@Override` en la implementación de métodos de interfaces proporciona claridad y seguridad en el código. Al indicar que un método está sobrescribiendo uno de una interfaz, el compilador verifica que este método realmente implementa uno definido en la interfaz. Esto ayuda a evitar errores, como incorrectas firmas de métodos que podrían pasar desapercibidos. Además, mejora la legibilidad, indicando a otros programadores que la intención es sobrescribir un método y no crear uno nuevo. En resumen, es una buena práctica que refuerza la correcta implementación de interfaces.
tengo una duda, los mappers no deben de usarse de forma recomendable en la capa de servicio?
Interesantinggg omggg 🤯
¿Dónde se le puede dar like a la clase? jeje excelente explicación 😎🎉
Cuando le hacemos el mappeo de Product a Producto en la clase ProductRepository del dominio nos estamos olvidando del valor del atributo `codigo_barras` que la tabla espera. Para tenerlo en cuenta más adelante, debemos generarlo en nuestra lógica o calcularlo.
En este punto se siente que va demasiado r'apido, quizas el ejemplo podria mejorarse
Está muy bien el curso, la verdad es que el profe explica muy claro. Pero definitivamente concuerdo con los demás en que el nombramiento de clases e interfaces se torna algo confuso y debería cambiarse. Se podría explicar el pseudo-patrón DTO de paso como lo menciona @fernandojerez más arriba. De todas forma buenísimo el curso, gran profesor.
Vengo de usar otros framework de back.... como NestJS... En algún momento usa los DTO?
El curso iba bien hasta que saco MapStruct... ya que estoy estudiando en un computador de la empresa para que laboro y no puedo instalar cualquier IDE.... estoy con VSCODE que iba super genial... Y si, pues puedo usar mi computador personal... pero entienden la limitación de usar librerías o IDE's super acoplados a algo que sinceramente es ajeno a Spring....
Por Dios siento que perdi mi tiempo con este curso...
alguien entendio porque hizo como hizo el getProduct y el save? Que me explique porfaaa!!
¡Muy bueno!
Es incorrecto decir más óptimo.
Se podría hacer el mapper en la capa de service para evitar tener tantos repositorios? o la responsabilidad de mapear es de un repositorio?
Significado de todo esto
Tengo una consulta que pasaría si en la clase ProductoRepository de persistence se usara
un ProductCrudRepository<Product,Integer> en ves de un ProductoCrudRepository ya que no se tuviere que convertir muchas veces o usar el famoso mapper es valido profesor?
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?