Por qué no puede haber SOLID sin Eventos de Dominio
Vložit
- čas přidán 9. 07. 2024
- Muchas veces intentamos aplicar SOLID en nuestro código, pero se nos complica. Con los Eventos de Dominio podemos solventarlo. En este vídeo exploramos cómo este patrón nos puede ayudar a tener un código más mantenible, escalable y testeable.
🔗 Aprende a Modelar Eventos de Dominio: pro.codely.com/library/modela...
﹤🍍﹥ 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
aprendo muchop con ustedes gracias saludos !
Explicación Excelente, como siempre. Dos preguntas: ¿Que protocolos aplicar cuando los casos de uso derivados fallan? y En los eventos de dominio, debe enviarse algún identificador, por ejemplo, id UUID del usuario creado para este caso?
Ufff, a ver, que yo también soy fan de los eventos de dominio porque hace el código más simple (entre comillas, en realidad lo más correcto sería decir que todo el acoplamiento se concentra a costo de "ofuscar", como pasa con la programación orientada a aspectos), lo cual tiene mucho sentido en según que arquitecturas/proyectos. Pero a mi entender el "guardar en bbdd" no está siendo responsabilidad del caso de uso, sino de la implementación de repository. Igual que el buscar si ya existe, que en vuestro esquema es responsabilidad del finder. La responsabilidad única del caso de uso es ejecutar todos los pasos esperados al "registrar un usuario". Digo más, el control de duplicados puede darse en un servicio para que tanto los pasos de búsqueda previa como guardado estén "unificados" (y cada uno de esos pasos se implementarían en el repository, que tiene la responsabilidad única de acceso al sistema de persistencia usado). O más acertado desde mi punto de vista: Delegar esa responsabilidad al repository, que trabaja a nivel de entidades de dominio, y que dicho repository acceda al sistema de persistencia usando DAOs más cercanos al sistema de persistencia específico (y por ende, 100% de la capa de infrastructura y un "detalle de implementación" del repository).
Vamos, que decir que "SOLID no se puede hacer sin eventos de dominio" me parece cuando menos una exageración derivada de interpretar que las responsabilidades "se heredan".
PD: Lo siento, pero mi experiencia dice que en la realidad eso de la independencia de equipos no se da. Suele haber bastantes problemas con el mensaje del evento (en realidad, justo los mismos problemas que con las respuestas de los microservicios. Ni más, ni menos).
iba a escribir palabra por palabra tu comentario, gracias por ahorrarme el rato, pulgarcito arriba
@@carlosad6706 jajajaja, gracias, los 20 min escribiendo y las 15 ediciones intentando expresar la idea correctamente han merecido la pena ya solo por eso 😁
Lo has clavado. Habiendo trabajado con ambos modelos puedo atestiguar que ambos son interesantes y útiles en su contexto, y que los Eventos de Dominio no son siempre lo más adecuado. Si a nivel de negocio no se contempla que registrar un usuario se pueda hacer sin notificar por Slack, entonces el UseCase debe reflejarlo. Se le pasa al repositorio o servicio encargado de mandar la notificación el resultado de ese insert previo y listo. Parece que se les haya olvidado que en programación puedes hacer cosas con el retorno de una función o algo 😂
Qué bien explicado! 🙌🙌
Genial explicación!
Otra solución para mantener el SRP sería hacer una capa que no contenga ningún tipo de lógica y se dedique únicamente a orquestar, pero estoy de acuerdo en que los eventos son muy útiles 😄
Gran explicación!!! +9999
thank you for nice content :D
Esperaba más jaleo en los comentarios y está la cosa tranquila. 🤣🤣🤣🤣🤣🤣
Cada dia el contenido que hacen es mejor en todos los sentidos. Saludos desde Costa Rica
Bien El tema de EventSoursing esta muy bueno y soluciona muchísimos problemas y no solo de que c/microservicio tiene su BD.
No me cierra nunca que cuando digan Microservicios siempre van a->.Diferentes BD ..replicas etc. Casi en un 90% se resuelve con la misma BD (Mirroriada podría ser) pero en fin la misma BD .-
Al menos que sea un requisito de altísima disponibilidad y performance ..y aislamiento tambien ahi si bueno poner su propia BD; Pero la mayoría de las veces se pueden tener Microservicios (que no son más que pc virtuales y conforman una lan virtual o no) y se podrían conectar a tu SQL si problemas en su misma lan Ej si tenes todo en Azure que problema hay??
Ok 5:39 me gusta esta explicación pero no me queda claro en el caso de los logs también se envían por evento? O eso no ? Y tienen q quedar al mismo nivel que el guardar usuario.?
Gracias por compartir.
Saludos
5:39
Si claro puede que el receptor de logs este centalizado en un Microservicio con su propio Motor y BD que luego es consumido por Tools o apps de analisis de performance, auditorias , error monitoring etc que no deba afectar al bussiness core en si.
Hay algo que no me queda claro cuando enfrentáis API vs Eventos de Dominio en la comunicación entre microservicios, al menos si nos ceñimos a nivel síncrono. Señaláis como algo negativo que una API debería exponer unos datos determinados para ser consumidos. Pero eso mismo hace lanzar un evento. Aún no me he metido de lleno en este curso, pero por ejemplo, el típico patrón Observer, para notificación de eventos, expone parte del observable (llamémosle una API de clase) para que los observers o consumidores puedan disponer de ello.
¿Alguien me lo aclara please?
🤯
Me genera dudas una cosa: entiendo que el caso de uso queda más simple y claro porque hace lo que se supone que tiene que hacer y luego publica un evento "a quien le interese, que sepas que esto ha ocurrido". Pero... ¿Y si hay lógica transaccional en todo esto? ¿Y si las acciones que se desencadenan tras lo que hace el caso de uso deberían hacerse y si fallan entonces dar por fallido todo el proceso? Entiendo (y perdonad si estoy diciendo barbaridades) que entonces no he entendido bien el caso de uso y que no era tan simple como yo pensaba. ¿Es así?
No has entendido mal, el caso de uso es el que controla la transaccionalidad del caso de uso (valga la redundancia). Es la forma de garantizar que "todos los pasos que se esperan que sucedan en el caso de uso" sucedan a efectos prácticos como una operación atómica. Para poder lidiar con ello en operaciones donde intervengan distintas aplicaciones existe el concepto de transacciones distribuidas, las cuales se pueden realizar de varias formas distintas dependiendo de la arquitectura concreta con la que se trabaje.
No veo claro la interpretacion que haceis de la S de SOLID. Conectarlo indisolublemente con Eventos de Dominio lo veo menos todavia. ¿Habeis leido el paper de SOLID?
Evento de dominio o evento de aplicación?
Dominio.