Orientar nuestro repositorio a términos del dominio

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

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.

Que confuso, 3 repositorios de productos …

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 😉

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.

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);

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

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.

“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.

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

Que confuso se volvio este curso

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

Aquí me perdí profe, ya no te entendí nada 😦

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

¡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?