Saludos 'Product Crafter', vi tu video y he revisado tus demas videos, parece que tienes un enfoque mas profesional, de la estructura, estetica, eficiencia del codigo. Al principio no te tenia fe, al ver la sugerencia de tu video por parte de RUclips, crei que eras otro vende humos mas de RUclips en cuanto a 'Coding', que solo busca ganar dinero con vistas, likes, membresías de canal, vender cursos, pero parece que no es asi, al contrario veo tu ❤ amor por el 'Coding', como crear excelentes pautas de arquitectura, estetica, eficiencia en el mismo, personas como tu son como el Mozart de nuestra epoca, hacen que me enamore mas del 'Coding'❤️, gracias mi compa.
No le veo nada de malo a hacer contenido y querer recibir vistas y likes. Es un sentimiento natural en el ser humano querer recibir reconocimiento y sentirse útil. Aunque lo hiciera por likes el calificativo de "vende humos" está fuera de lugar en este contexto.
Gracias por los vídeos, son increíbles, es complicado encontrar canales en español que hablen de estas cosas! Podrías subir algún vídeo más centrado en temas de arquitectura, diseño, events/CQRS y relacionados?
Hola! muy buenos videos, facil de entender y se entiende la idea, me queda una duda, cuando aprendí a utilizar este concepto de value objects o definicion de logica de negocio, lo hice en pydantic, cual sería la diferencia con dataclass?
Entiendo la manera de explicar los value objects como un concepto que tiene lógica de negocio o como valores que no necesariamente tienen sentido por separado (como pesos, precios...) pero para algunos cerebros como el mío es algo que hay que llevarlo a conceptos más "de bajo nivel" (me quedo corto con las comillas). Para mí un value object es algo (una estructura) que cuando comparas con otro son iguales si y solo si sus valores (todos ellos) son iguales, siendo estos inmutables. En OOP serían objetos que se consideran iguales si todos sus valores son iguales. Esto es contrario a las entidades, como usuarios, que pueden ser mutables (un usuario puede cambiar su dirección) y que cuando comparas dos comparas identificadores, por ejemplo. En mi opinión esto es importante porque en otros lenguajes no estamos hablando solo de conceptos que se pueden agrupar como tal. En general dos objetos, estructuras o lo que sea (salvo primitivos) son iguales si apuntan a la misma dirección de memoria. Esto, que para ingenieros informáticos es lo intuitivo, es el concepto contrario a los value objects, otra manera de pensar. Por eso se devuelve siempre una copia del objeto en vez de mutar el mismo. Pensar así te abre también a entender cosas como el borrow checker de rust o te hace entender que en ciertos casos no interesa hacer lógica en base a value objects porque son muy costosos en cuanto a memoria. Igualmente, buen enfoque, solo quiero añadir mi punto de vista!
Gracias por compartir tu punto de vista! Te hago una pregunta porque yo tengo siempre la duda, si tenemos un value object que representa peso que tiene unidad y cantidad, imagina que tenemos 2kg y 2000g. Yo si comparo los dos value objects espero que me diga true. Pero sin embargo no tienen los mismos atributos (2 vs 2000 y g vs kg). ¿Son Value Objects o estamos haciendo algo mal?. Es algo que le he dado mil vueltas y para mi sí son Value Objects. Que los "atributos" sean iguales también podría expresarse como que sus valores sean "equivalentes".
@ProductCrafter si, son lo mismo porque conceptualmente tienen el mismo valor expresado de distinta forma. Creo que piensas como yo y te vas al concepto programático de valor en vez de al concepto 😆 A mi también me cuesta abstraer. El problema viene siendo con cosas cuyo valor es dinámico, como el cambio de divisas. En ese caso habría que llegar a un convenio en la lógica de negocio (histórico de precios de los últimos 5 años, consultar una API de manera dinámica...). Pero lo podemos complicar aun más. Son lo mismo 1dm3 que 1l? Si y solo si tienen la misma densidad que el agua. Importa? Si es una app de cocina, generalmente no. Pero si es de quimica... Cuando me pasan estás cosas pienso en la inmutabilidad como concepto y en la lógica de negocio. Por ejemplo en divisas, aunque consultar el cambio a una API es dinámico, el concepto de "es inmutable que siempre se va a comprobar el cambio dinámicamente" es lo que me ayuda. A mí también me explota la cabeza cuando sobre pienso, y eso que yo vengo del mundo de la ciberseguridad 😊 Por cierto, me he estado viendo todos los videos que tienes en el canal, bastante de acuerdo con tu linea de pensamiento! Gracias por estos vídeos!
Sí, otro ejemplo podría ser Coordinate con las propiedades latitude, longitude o DateRange con startDate endDate. No podemos olvidar que los value objects pueden tener solo una propiedad, por ejemplo Email, por sí solo no tiene sentido, pero sí puede formar parte de otros value objects o entidades/agregados, esto nos permitirá centralizar, reutilizar y abstraer los tipos.
Tener un ValueObject Email es super util ya que validas que el string que viene por el factory method o por constructor tenga el formato correcto, dentro del value object podrias poner el Regex para validarlo. Lo mismo para una ValueObject PhoneNumber, etc. Incluso se puede tener value objects por campos aislados como UserName porque un username valido solo tiene caracteres con letras, debe tener minimo 5 caracteres, no puede estar vacio, etc. Tiene la contraparte que te aumanta considerablemente el codigo si el lenguaje es fuertemente tipado y poco funcional. Pero como dice el muchacho en el video, eso tiene el beneficio de ser robusto y mucho mas facil de mantener a largo plazo. Ademas que es mas facil de leer.
Gracias por preguntar! Hay varios patrones. Por ejemplo un value object coordenadas que tuviese los atributos latitude y longitude podías guardarlos en la tabla tal cual como latitude y longitude o asignarles un prefijo como por ejemplo location_latitude y location_longitude para dejar claro que esos dos campos pertenecen a un concepto que los engloba llamado location. Las dos están bien y depende el contexto puede quedar más clara una o la otra. Cualquier duda más dime!
creo que el ejemplo con pesos no deja en claro muchas cosas. Si uno define un peso como kg si queremos decir que son 500 gramos pasamos 0.5. En las bases de datos se usan floats para los pesos para permitir justamente este tipo de casos. El ejemplo sería mejor para monedas y hacer conversiones por ejemplo entre Dólar y Euro y hacer transferencias de dinero usando la conversión que tenemos, en el caso de pesos no lo veo muy claro. Si fuesen temperaturas también tendría sentido ya que podrían ser celsius o Fahrenheit. Decir que algo pesa 500 gramos o 2 kilos no tiene sentido, se usan o gramos o kilos y listo
Si que es verdad que como la transformación entre kg y g es intuitiva no se ve tan claro el valor que aporta, aun así encapsulándolo en un Value Object tienes las ventajas de la validación (no tienes pesos negativos) y de poder transformar entre unidades. Gracias por el apunte!!
Es otra forma de programarlo sÍ, también se podrían haber implementado factory methods en el value object para instanciar desde diferentes unidades pero acabar siempre en gramos. Para mi lo importante es darle ese significado de "Peso" que conseguimos dándole entidad de negocio, pero hay muchas maneras de representarlo. Gracias por el comentario!
@@davidmataviejo3313 concuerdo contigo, lo q mas apesta en pythton y no tolero es que no tenga corchetes, que los tabs o espacios sean la regla, como odio eso, y al final todo son libs hechas en cpp u otro lenguaje
Primer video de tu canal que veo, me encantó tu manera de explicar. Nuevo sub
Gracias! Si quieres un video sobre algún contenido en especial dime!
Saludos 'Product Crafter', vi tu video y he revisado tus demas videos, parece que tienes un enfoque mas profesional, de la estructura, estetica, eficiencia del codigo. Al principio no te tenia fe, al ver la sugerencia de tu video por parte de RUclips, crei que eras otro vende humos mas de RUclips en cuanto a 'Coding', que solo busca ganar dinero con vistas, likes, membresías de canal, vender cursos, pero parece que no es asi, al contrario veo tu ❤ amor por el 'Coding', como crear excelentes pautas de arquitectura, estetica, eficiencia en el mismo, personas como tu son como el Mozart de nuestra epoca, hacen que me enamore mas del 'Coding'❤️, gracias mi compa.
No le veo nada de malo a hacer contenido y querer recibir vistas y likes. Es un sentimiento natural en el ser humano querer recibir reconocimiento y sentirse útil. Aunque lo hiciera por likes el calificativo de "vende humos" está fuera de lugar en este contexto.
Gracias por el comentario! ❤️ La verdad es que me motiva mucho enseñar y RUclips es el medio perfecto! Espero que te sigan gustando mis videos!
Muy bien explicado y ameno. Mil gracias!!
Me suscribo al instante :D
Gracias! 🙌
Muy bueno!! Muy clara la explicación... Muchas gracias 🙌🙌🙌🙌
Gracias! Me alegra que te haya gustado!
excelente video, opino igual que tu , me encantan los valueobject
Gracias!
Gracias por los vídeos, son increíbles, es complicado encontrar canales en español que hablen de estas cosas! Podrías subir algún vídeo más centrado en temas de arquitectura, diseño, events/CQRS y relacionados?
Claro! Tengo algunas ideas sobre arquitectura que quería hacer, tengo en cuenta tus sugerencias gracias!
Hola! muy buenos videos, facil de entender y se entiende la idea, me queda una duda, cuando aprendí a utilizar este concepto de value objects o definicion de logica de negocio, lo hice en pydantic, cual sería la diferencia con dataclass?
Es lo mismo, simplemente pydantic tienes que instalarlo, pero para value objects cumplen la misma función
Entiendo la manera de explicar los value objects como un concepto que tiene lógica de negocio o como valores que no necesariamente tienen sentido por separado (como pesos, precios...) pero para algunos cerebros como el mío es algo que hay que llevarlo a conceptos más "de bajo nivel" (me quedo corto con las comillas). Para mí un value object es algo (una estructura) que cuando comparas con otro son iguales si y solo si sus valores (todos ellos) son iguales, siendo estos inmutables. En OOP serían objetos que se consideran iguales si todos sus valores son iguales. Esto es contrario a las entidades, como usuarios, que pueden ser mutables (un usuario puede cambiar su dirección) y que cuando comparas dos comparas identificadores, por ejemplo.
En mi opinión esto es importante porque en otros lenguajes no estamos hablando solo de conceptos que se pueden agrupar como tal. En general dos objetos, estructuras o lo que sea (salvo primitivos) son iguales si apuntan a la misma dirección de memoria. Esto, que para ingenieros informáticos es lo intuitivo, es el concepto contrario a los value objects, otra manera de pensar. Por eso se devuelve siempre una copia del objeto en vez de mutar el mismo.
Pensar así te abre también a entender cosas como el borrow checker de rust o te hace entender que en ciertos casos no interesa hacer lógica en base a value objects porque son muy costosos en cuanto a memoria.
Igualmente, buen enfoque, solo quiero añadir mi punto de vista!
Gracias por compartir tu punto de vista! Te hago una pregunta porque yo tengo siempre la duda, si tenemos un value object que representa peso que tiene unidad y cantidad, imagina que tenemos 2kg y 2000g. Yo si comparo los dos value objects espero que me diga true. Pero sin embargo no tienen los mismos atributos (2 vs 2000 y g vs kg). ¿Son Value Objects o estamos haciendo algo mal?. Es algo que le he dado mil vueltas y para mi sí son Value Objects. Que los "atributos" sean iguales también podría expresarse como que sus valores sean "equivalentes".
@ProductCrafter si, son lo mismo porque conceptualmente tienen el mismo valor expresado de distinta forma. Creo que piensas como yo y te vas al concepto programático de valor en vez de al concepto 😆 A mi también me cuesta abstraer. El problema viene siendo con cosas cuyo valor es dinámico, como el cambio de divisas. En ese caso habría que llegar a un convenio en la lógica de negocio (histórico de precios de los últimos 5 años, consultar una API de manera dinámica...). Pero lo podemos complicar aun más. Son lo mismo 1dm3 que 1l? Si y solo si tienen la misma densidad que el agua. Importa? Si es una app de cocina, generalmente no. Pero si es de quimica...
Cuando me pasan estás cosas pienso en la inmutabilidad como concepto y en la lógica de negocio. Por ejemplo en divisas, aunque consultar el cambio a una API es dinámico, el concepto de "es inmutable que siempre se va a comprobar el cambio dinámicamente" es lo que me ayuda. A mí también me explota la cabeza cuando sobre pienso, y eso que yo vengo del mundo de la ciberseguridad 😊
Por cierto, me he estado viendo todos los videos que tienes en el canal, bastante de acuerdo con tu linea de pensamiento! Gracias por estos vídeos!
Sí, otro ejemplo podría ser Coordinate con las propiedades latitude, longitude o DateRange con startDate endDate. No podemos olvidar que los value objects pueden tener solo una propiedad, por ejemplo Email, por sí solo no tiene sentido, pero sí puede formar parte de otros value objects o entidades/agregados, esto nos permitirá centralizar, reutilizar y abstraer los tipos.
Exacto!!
Tener un ValueObject Email es super util ya que validas que el string que viene por el factory method o por constructor tenga el formato correcto, dentro del value object podrias poner el Regex para validarlo. Lo mismo para una ValueObject PhoneNumber, etc. Incluso se puede tener value objects por campos aislados como UserName porque un username valido solo tiene caracteres con letras, debe tener minimo 5 caracteres, no puede estar vacio, etc. Tiene la contraparte que te aumanta considerablemente el codigo si el lenguaje es fuertemente tipado y poco funcional. Pero como dice el muchacho en el video, eso tiene el beneficio de ser robusto y mucho mas facil de mantener a largo plazo. Ademas que es mas facil de leer.
@ divide y vencerás
Buen contenido! pequeño apunte Weight se pronuncia parecido a Wait, no 'weiz'
Gracias!! 🤦♂️ Fallitos de estos nunca me doy cuenta, ya no me vuelve a pasar con Weight!
y como mapearias los value objects a una base de datos?
Gracias por preguntar! Hay varios patrones. Por ejemplo un value object coordenadas que tuviese los atributos latitude y longitude podías guardarlos en la tabla tal cual como latitude y longitude o asignarles un prefijo como por ejemplo location_latitude y location_longitude para dejar claro que esos dos campos pertenecen a un concepto que los engloba llamado location. Las dos están bien y depende el contexto puede quedar más clara una o la otra. Cualquier duda más dime!
yo solo vine a burlarme por q era python pero aprendi mucho :D
Jajajaja me alegro! Al final le coges el gustillo a Python jaja
creo que el ejemplo con pesos no deja en claro muchas cosas. Si uno define un peso como kg si queremos decir que son 500 gramos pasamos 0.5. En las bases de datos se usan floats para los pesos para permitir justamente este tipo de casos. El ejemplo sería mejor para monedas y hacer conversiones por ejemplo entre Dólar y Euro y hacer transferencias de dinero usando la conversión que tenemos, en el caso de pesos no lo veo muy claro. Si fuesen temperaturas también tendría sentido ya que podrían ser celsius o Fahrenheit. Decir que algo pesa 500 gramos o 2 kilos no tiene sentido, se usan o gramos o kilos y listo
Si que es verdad que como la transformación entre kg y g es intuitiva no se ve tan claro el valor que aporta, aun así encapsulándolo en un Value Object tienes las ventajas de la validación (no tienes pesos negativos) y de poder transformar entre unidades. Gracias por el apunte!!
Pues raro tu codigo yo pondria todo en gramos y solucion hecha. Pondria el tipo en numero entero sin signo. La verdad no se si se mejoro el codigo
Es otra forma de programarlo sÍ, también se podrían haber implementado factory methods en el value object para instanciar desde diferentes unidades pero acabar siempre en gramos. Para mi lo importante es darle ese significado de "Peso" que conseguimos dándole entidad de negocio, pero hay muchas maneras de representarlo. Gracias por el comentario!
preferia que utilices programacion funcional con interfaces
Lo probaré!
Es horrible python, nose como se hizo tan popular xd
En general porque es fácil de aprender y de enseñar!
Python es horrible cuando se usa programación orientada a objetos. El autor debería usar java, kotlin o c# para explicar estos temas
@@davidmataviejo3313 concuerdo contigo, lo q mas apesta en pythton y no tolero es que no tenga corchetes, que los tabs o espacios sean la regla, como odio eso, y al final todo son libs hechas en cpp u otro lenguaje