Diferencias entre Value Object vs Entidad vs Agregado
Vložit
- čas přidán 27. 09. 2023
- Hay términos en los patrones de programación que pueden ser muy confusos. Tanto en el dominio como en la infraestructura llevando, por ejemplo, los Agregados a la Base de Datos ¿1 Agregado = 1 Tabla?
Curso de Agregados: bit.ly/curso-agregados
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
Técnicamente es lo mismo que sugiere MongoDB con muchos JSON por todos lados. El problema está en cuan importante es la consistencia de los datos para tu sistema. Esta via es valida para aquellos datos que tienen poca probabilidad de cambiar, algo semejante a cuando deseas añadir una cache en tu sistema. Si los datos no cambian o cambian poco es perfecto, sino preparate para la inconsistencia...
Que fascinante que justo ayer que me estaba topando con este problema en un proyecto personal, y no estaba encontrando una respuesta, y vienen ustedes y sacan este video 🤯🤯🤯🤯
Oro lo q se ha expuesto, muchas gracias!
Gracias por el comentario 😊
¿No estamos creando un híbrido entre BD relacionales y no relacionales? O camuflando una BD no relacional dentro de una relacional. ¿Para eso no es más fácil usar directamente una NoSQL?
Contenido de calidad, por fin algo que no es un cursó desde cero, a mi opinión personal claro ❤
Yo una duda que he tenido siempre, es cómo persistir en una base de datos relacional un agregado que contiene un array de value objects (por ejemplo, un usuario que puede tener N direcciones). Tradicionalmente lo vengo haciendo añadiendo como una columna tipo JSON en la tabla del agregado, pero no estoy seguro de que sea la mejor solución. Lo único que veo es sacarlo a una tabla a parte y poner como PK toda la fila, pero tampoco estoy seguro de esto jeje.
excelente video, queremos mas DDD
No me quedó clara la respuesta final a la GRAN pregunta expresada por el compañero. La solución del JSON responde al caso de que la necesidad se pueda resolver así. Pero si no se puede resolver así, y se necesita una tabla auxiliar, ¿Cómo se resuelve el tema de múltiples repositorios o si existe una manera de pasar el agregado completo y que, internamente se gestione todo lo que haya que insertar y sus relaciones.
Tambien me quede con la misma duda, podria ser que el controlador inyecte 2 servicios? uno para la creacion del address y otro para la creacion del usuario o que el servicio de creacion de usuario inyecte el servicio de creacion de address? quizas rompi varias reglas pero bueno jaja
Como siempre contenido de tremenda calidad ❤
Gif de Javi diciendo "El diablo se esconde en los detalles" para ser espameado sin pudor en Teams creado.
muy chulo el video mil gracias por los ejemplos tan claros!, el tema de meter el address en el user me parece un poco trambolico, mas q nada xq hoy puede parecer q solo hay 1 direccion pero mañana pueden ser 3 y ya tienes q estar con migraciones feas, y el rendimiento ganado es minimo. eso si como decis todo dependera de las necesidades del proyecto. Gran video como siempre ❤
Totalmente de acuerdo con todo. La unica duda que tengo es, en el ejemplo del tweet se proyecta el username. Si el usuario cambia ese campo, deberemos recorrer toda la tabla de tweets para actualizar ese campo en todos los tweets que haya dado like, no?
Esperemos la opinion de Codely, pero creería que sí, pero que tendría que analizarse cuantos likes da un usuario cada x tiempo para ver si tal vez es mejor una proyeccion de usuario que han hecho like, para hacer un join a esa proyección. pero nada pensando en voz alta, ya veremos.
Excelente vídeo, me surge la duda de que pasa cuando implemento CQRS, ya que por ejemplo, puedo tener un producto que tenga muchas imagenes, las imágenes pertenecen al producto, pero que pasa cuando creo mi CreateProductCommand, de que manera modelo las imágenes para hacer la carga en cascada de imágenes al producto?
Chulada de contenido saludos
Excelente ejemplo 🎉🎉
Me gusta la idea de hacer valueObjects para las propiedades de la clase principal. Pero esto si esto se repite constantemente ¿Pudiese ser contraproducente por los recursos que llega a consumir la API a nivel de infra-estructura? Basandonos en que la inicialización de clases consume recursos. Mas recursos que tener un service que maneje flujos por casos de uso, manejando propiedades primitivas en campos como likes. Me gustaría saber su opinión con respecto a esto por favor. ❤ ¡Gracias por el vídeo esta espectacular!
Que pasa si tengo varias entidades que usan Address y que tienen todos el mismo schema? Puedo usar una tabla Address general e identificarlos por tipo de a quien le pertenece? Ahí si tendría sentido un id y quizas poner el id del addres en el usuario o entidad al que le pertenezca? o seria mejor una tabla intermedia? ❤
Yo tengo una duda similar, en el ejemplo de los posts, supongamos que el post tiene un status, el cual puede ser publicado, borrador, inactivo o eliminado, a nivel de base datos me conviene tener un tabla post_status como VO o solo tener el campo status tipo integer y en el dominio en el VO de status tener un enum de los posibles status ? 🤔
muy bueno el vid como siempre! tengo una duda, a ver si estoy en lo correcto: en el primero ejemplo, del post y los likes, dado el caso de que un user quisiera modificar su username, debería yo entonces recorrer todos los post likeados, y pedirles que actualicen mis datos de usuario? en ese caso, que recomiendan? tener algun tipo de referencia a todos los likes hechos por un usuario? o una referencia a todos los posts likeados por un usuario? dado que el aggRoot es el post, y que el Like esta dentro del Agg, que un usuario tenga acceso a sus likes sería romper ese "encapsulamiento" del agregado o estaría bien? Gracias..!!
Una duda, como se gestionaría estos casos pero donde tenemos una clase que sirve simplemente para gestionar la ídempotencia del aggregate Root?
¿Una base de datos de lectura (redis o mongo) sería un paso más allá o ya es válido en esos casos?
Y no se tendría en cuenta el concepto de asociación ( Entidad) o composición ( VO) del agregado?
cuando entra una nueva persona al proyecto y quiere editar algo en el rename del usuario del like, como sabrá donde buscar el método? digo eso de los agregados lo puedes definir tu ahora, pero una persona nueva que entre a este proyecto y tu ya te fuiste de la empresa realmente no le veo una lógica de como ubicaría RenameUser en un agregado llamado Post, realmente me parecen conceptos muy alejados, sigo pensando en que o DDD no es fácilmente escalable ni mantenible o ustedes lo están aplicando mal.
Son unos chingones, voy a pagar la anualidad.
Buen contenido, pero a momentos no entiendo lo que está diciendo Rafa, habla un poco rápido.
🙏🙏🙏
Os tendrían que hacer funcionarios. Seguid haciendo el bien.
Cada vez me gusta menos DDD
porque le dais tanta vuelta a una explicacion que en 3 minutos se hace? y para que usas un ejemplo de un microBlog?? será que muchos hacemos twiters?? con algo como Pedido
Cliente
Producto seria hasta suficiente de una ordenPedido!