Entidades y Agregados: El momento en el que hicimos “click” y entendimos esta parte de DDD

Javier Ferrer y Rafa Gómez:🌋 Entidades y Agregados: El momento en el que hicimos “click” y entendimos esta parte de DDD.
Los agregados son uno de los principales elementos en Domain-Driven Design. En resumen, vienen a ser entidades con ciertas restricciones adicionales, pero… la primera vez que te enfrentas al concepto y lo llevas a la práctica te surgen mil dudas:
¿Qué diferencia un agregado de un aggregate root y una entidad?
¿Cómo de grandes tienen que ser?
¿Qué pasa si tengo que devolver datos de varios agregados?
¿La lógica va dentro del agregado? ¿en los Value Objects? ¿en servicios de dominio?
¿Qué relación tienen con read y write model?
¿Cómo podemos evitar que haya una explosión de métodos?
💆‍♀️💆‍♀️💆‍♀️ Keep calm 💆‍♀️💆‍♀️💆‍♀️
En esta charla daremos nuestro punto de vista al respecto de estas cuestiones y compartiremos ejemplos concretos. Veremos el momento concreto en el que “hicimos click” y el diseño de nuestro dominio encajaba con un enfoque que nos cuadraba. 😊

[@andresperalta8791]

Minuto 42:06 es una pregunta clave, ya que si, para cada caso es más óptima una solución ¿cómo sabemos si el proyecto va a crecer o si se debe aplicar todo esto a un proyecto ya recorrido? en tal caso implicaría una reingeniería de toda la aplicación o irla migrando poco a poco. Lo que si veo importante es ir aplicando ciertos principios en especial que favorezcan la cohesión y mitiguen el alto acoplamiento para poder migrar a otras soluciones sin mayor dificultad.

[@josecelano]

Buena charla. Quizás mucha información de golpe. Pero es un buen resumen de las opciones y pros/cons. Hay una cosa que yo siempre tengo la duda y nunca se comenta en este tema. Creo que Javi comenta que las proyecciones se usan porque a nivel de negocio una parte se quiere escalar y se quiere independencia de la otra, así que gestiona sus propios datos. En definitiva, supongo que es el único caso en donde los datos están en tablas o base de datos independientes. En el modelo de repository los modelos de escritura y lectura comparten las misma tablas. Yo cuando he hecho eso he visto que los modelos quedan limpitos pero como mencionan en el video los prepositorios son un infierno. Los innerjoins están todos ocultos. No me parece un problema que estén ocultos pero si veo un problema en que el acoplamiento se ha bajado de nivel, es decir, los modelos no están acoplados entre sí, pero ambos están acoplados a la misma persistencia. EN la práctica cuando cambias un campo como el precio del producto de nombre, si eso afecta al nombre del campo en la base de datos, tienes muchos innoerjoins rotos que son muy complicados de arreglar. Además es una parte jodida de testear, porque normalmente es lo que moqueas. ¿Cómo gestionan ese tema?. Yo creo que si tu aplicación es intensiva en modelos de lectura (muchas vistas y inner joins) el modelos de proyeccciones puede compensar en local aunque tengas un solo equipo. Los innerjoins para mí son un infierno aunque no tengas problemas de rendimiento. Pero claro no tengo mucha experiencia con proyecciones (solo las he implementado en local, dentro de la misma app), pero creo que los problemas que da son más manejables, y sobre todo es escalable y más fácil de modificar.

[@montreux82]

No me quedo claro cual es la solucion final al problema de listar productos que a su vez conlleva pedir los reviews y tambien usuarios.

[@SchenierLopez]

El vídeo no es explicación de cómo listar los productos con sus reviews y usuarios 😅. Puedes listar los productos con join. El vídeo es para alternativas, en este caso, arquitectura limpia

[@jstsamuel]

Javi y Rafa de negocio xd

[@yagolopez6186]

Estamos llegando ya al paroxismo de la sobreingeniería y la hipercomplejidad innecesaria. Buen ejemplo de cómo pisotear uno de los principios más importantes de Ingeniería del Software (incluso de la Ingeniería en general) Keep It Simple. Así nos va.

[@kodenix]

Se hace bastante incapié en que depende del contexto, hay casos mas simples y casos mas complejos. En casos muy complejos (reales) a veces requiere soluciones complejas en algun punto para mantener simple el resto. Así nos va si tomamos decisiones muy grandes de ingenieria en etapas muy tempranas de proyectos donde no podriamos iterar en el futuro, pero si a lo largo del tiempo requerimos implementar soluciones complejas (porque no existe alternativa) es lo que hay, para eso hacemos ingenieria.

[@leow375]

​@@kodenixclaro depende del contexto, si necesitas desacoplar un modulo de tu aplicación para dárselo a un equipo esto podría ser una opción pero eso no quiere decir que sea la única, para un contexto simple esta puede ser una solución compleja, pero para un contexto complejo está puede ser la solución correcta

[@Sam-hu3xt]

Bien dicho!, somos ingenieros no? Hagamos honor a eso.