Conoce mi curso de Arquitecturas Limpias 👉platzi.com/arquitecturaslimpias Si no te tienes suscripción en Platzi, usa mi enlace de afiliado: platzi.com/l/manuelzapata/
La lógica del negocio (LN) Es lo que la empresa tiene que hacer haya o no haya sistema 1. No amarres la LN a la bd 2. No poner la LN en el cliente 3. No poner LN en los controladores 4. Evita depender de terceros 5. Usa el patrón de diseño strategy 6. Usa el patrón de diseño template method 7. Falla lo más pronto posible 8. Evita devolver string como resultado 9. Conocer las capas de lógicas
Manuel, en ese video me gustaría tener mayor claridad sobre por qué existe una lógica distinta en el cliente y otra en el servidor, ¿si la lógica es lo que hace siempre la empresa, no sería solo una?
Fabio, aquí estamos hablando de la lógica de negocio. También existe la lógica de presentación, que es la que maneja sí o sí la interfaz gráfica. Saludos!
Lógica de Negocio = LN Objetivos a cumplir de la empresa con o sin sistemas de información. Recomendaciones: - Separar LN de la base de datos. - No meter la LN en los componentes UI. - No meter la LN en los controladores. - Evitar depender de terceros (APIS, Teconologías x como Gmail, etc...). - Patrón de diseño STRATEGY recomendado (si aplica). - Patrón de diseño TEMPLATE METHOD recomendado (si aplica). - Seguir el principio "Fail Fast", o que el código falle lo más rápido posible, para reducir costos. - La LN no debe devolver Strings como resultados (dificulta el desarrollo multi idioma en la UI y es frágil) | Usar Booleanos o tuplas. - Conocer patrones específicos para la LN. - Script de Transacción (muy usado). - Modelo de Dominio. - Módulo de Tabla. - Capa de Servicios (muy usado).
Buen video Manuel, de hecho los consejos que das cuando se aplican ...se obtiene como resultado una gran modularizacion o encapsulamiento de código, y con ello aparece otro dilema para los devs, y es la organización o estructura de proyecto, que si bien muchos Frameworks ya te dan una orientación de cara este tema, en la gran mayoría de las veces eso no es suficiente y solo con la experiencia se logra entender la manera adecuada de organizar o estructurar los directorios y ficheros. Me gustaría que hablaras de este tema de organización de proyecto, puesto que como arquitecto de software, posiblemente tienes mucho que aportarnos.
" 1. No amarres la LN a la bd 2. No poner la LN en el cliente 3. No poner LN en los controladores " ¿Y entonces donde ??? jeje , yo creo que va en mayor parte en el controlador y en menro parte solo conformando querys y ejecutandolas en los modelos. En la vista nada
Si la lógica de negoció no va en los componentes de Interface Gráfica y tampoco va en los Controladores entonces donde va ? No entendí si me puedes orientar
Estaría bien siempre del Controller comunicarme con un Facade y este a su ves los servicios? De esta manera no agrego la lógica en el controller y encapsulo todo en el Facade?
Muy buen video! Una consulta, la lógica de negocio debería estar centralizada en una sola capa de la aplicación? Existe algún patrón que indique como hacer una correcta lógica de negocio ?
Revisa el consejo #9, Adrián. Ahí menciono patrones específicos para el dominio. Concentrar la lógica de negocio en una sola capa? Yo creo que sería lo ideal, sin embargo he visto implementaciones donde se distribuye en varias partes.
Estuve peleando con un código por 1000 años y de lo dejé ahí para que se arregle solo, pero este vídeo me inspiró a levantarme, abrir el IDE y resolverlo. De corazón gracias!
Hablando de amarres de la logica de negocio a los diferentes componentes seria interesante un video sobre Clean Architecture, que expone conceptos que ayudan al desacoplamiento de los componentes.
Muy buen video Manuel. Lo que no me quedó claro es que mencionas que la lógica no debe llevarse a cabo dentro del controlador del patrón MVC. Entonces donde debería si la idea es no pasárselo a la base de datos ni a la vista?
Muchas gracias por el video Manuel, siempre claro y enriquecedor. Quede con ganas de ver el video que planteaste sobre: Que tipo de lógica poner del lado del cliente y cual del servidor. Ojala que lo puedas hacer. Muchas gracias. Acabo de chequear antes de enviar el mensaje que lo hiciste. Genial!!!! lo veré. Saludos desde Argentina!!!
La mejor solución es con patrones de diseño que en el caso de la base de datos podemos usar el Factory Method para que nos traiga el objeto de tipo Connection de JPA independientemente del driver que se utilice, y también tenemos que conocer lo que conoce como inyección de dependencias para hacer sistemas con un bajo acoplamiento
Excelente información! Gracias Manuel, muy interesante la aplicación de patrones y la separación de la lógica de negocio, no había pensado en las tuples 👌🏾
Buenas tardes, arquitecto. No soy de escribir en tu canal, solo felicitarte de tomar tu tiempo de compartir tus conocimientos valiosos sobre software. Te digo que me gustaría que en algun video explicases la capa de servicio, lo que conlleva y la diferencia con la capa de negocio, que suele estar en el dominio segun ddd. Gracias
Muchas gracias, tus consejos siempre me ayudan. Me quede con la idea de que tiene un BtnGuardar y el el evento click... ¿como lo harías, podrías darme un ejemplo? Para terminar de aterrizar la idea. Saludos desde México.
Hola Viktor! 👋 Se puede hacer de varias formas. Si ves que tienes mezclada la interfaz gráfica con la lógica de negocio en el mismo archivo, solo sácala a un archivo/clase aparte y llama funciones de la lógica desde los manejadores de eventos. Saludos!
Hola Manuel, excelente video como siempre. Tengo un par de preguntas en las que me gustaria conocer sus ideas. Con respecto al punto 1, precisamente en estos días he estado leyendo mucho sobre el repository patterm y he visto muchos artículos donde lo califican de anti patrón y de sobre abstracción si se usa con un ORM como Entity Framework por ejemplo, esto porque EF ya implementa el patrón, el DbContext es un unit of work y cada DbSet es un repositorio en si mismo. ¿Qué opinión tiene al respecto?. Lo segundo va un poco en relación a lo anterior, ¿me gustaría saber cuál considera una buena aproximación a una arquitectura en capas para un desarrollo empresarial? La aproximación a la que estoy llegando en este momento es la siguiente: Una capa Core con abstracciones de la logica del negocio (interfaces), abstracciones de los repositorios en caso de usarse y no sé si los modelos deberian ir aquí. Una capa a la que llamo de servicios o de implementación de lógica de negocio en la que implemento las interfaces de la capa anterior (aquí materializo los casos de uso que describí en las interfaces de la capa anterior). Capa de presentación. Espero esto no sea muy largo de leer. Gracias y siga así con el canal.
Hola Luis! Efectivamente, el repository y el ORM se solapan de alguna manera. No sé si llegar al punto de llamarlo antipatrón, pero ciertamente hay que saber manejar los 2 en conjunto. En cuanto a lo segundo, creo que vamos por enfoque muy Clean Architecture o Arquitectura Hexagonal. Quizá ya estás familiarizado con ambas arquitecturas, pero creo que estas te pueden dar una idea para validar tu enfoque. Saludos!
Son diferentes. Puedes profundizar en este libro de Martin Fowler: amzn.to/3kvLJJI O en mi curso de patrones de arquitectura: cursos.manuelzapata.co/inscripcion-curso-practico-patrones-arquitectura/
También quedo atento al video sobre que tipo de lógica debe ir en donde! Jeje. Y adicional... o quizás sea tema de ese video; es necesario hacer validaciones tanto en el front como en el back?
Hola Alfonso. En escenarios complejos de negocio se van volviendo necesarios. No los traje a mención en este vídeo por ser algo más especializado que en aplicaciones más sencillas no se necesita. Saludos!
Excelente vídeo. Me aclaraste muchas dudas. Y sí, me interesa que realices el vídeo de que lógica de de ir tanto en cliente como en servidor. También, me gustaría que hicieras un vídeo sobre Model Domain, veo que es usado para que le puedas explicar a una persona ajena al software y sin conocimientos de desarrollo para que entienda como funciona tu sistema. Saludos.
Hola Karin. Te agradezco la sugerencia. No creo que lo haga. Mi canal va por una línea diferente. Pero, nuestro canal amigo hdeleon.net fijo tiene contenido de LINQ: ua-cam.com/channels/DUdeFslCNoM29MAlZOfdWQ.html
Fantástico, por fin un buen canal en español, muchas gracias Manuel, te ganaste un suscriptor y muchos likes =) Esperaré el video de logica en el cliente y en el servidor !!!
Buen video. Sin embargo, tengo dos observaciones con respecto al cuarto punto. La primera es que el ejemplo de Gmail no es muy ilustrador porque finalmente uno no escribe lógica para Gmail específicamente, si no usando el protocolo SMTP, por lo que el proveedor si es restrictivo se puede cambiar por otro sin ningún problema. La segunda observación es que el concepto no es que no se deba depender de terceros. Dices que idealmente no depender de terceros, lo que puede implicar, en el ejemplo, construir mi propio sistema de mensajería y tampoco es la idea. Lo correcto es que en la lógica de negocio no se escriban rutinas que dependan de terceros específicos y abstraer esas dependencias en otras capas de forma tal que se puedan reemplazar sin afectar la lógica de negocio. Así las cosas, este punto se puede ejemplificar mejor con el caso del primer punto: no creo una dependencia frente a un motor de bases de datos específico en mi lógica de negocio sino que lo abstraigo a otra capa y puedo reemplazar en esa otra capa, o en otra implementación de esa capa, el motor en un futuro sin afectar la lógica de negocio.
Gracias por la retroalimentación Jhonny. Tienes toda la razón. El cuarto punto se pudo haber explicado de manera más clara, cómo lo describes. Espero que aún así, se haya podido transmitir el mensaje. Saludos!
Hola, excelente video, yo tengo una duda con el patron repository, a veces se necesitan hacer consultas complejas a la BD, y veo que las hacen en stores procedures en la BD, como pasarlas a un patron repository y que pueda yo si necesito cambiar luego mi BD de sql por ejemplo a mongo qie esto no sea traumatico, gracias y saludos Manuel.
Esa es una desventaja de usar procedimientos almacenados. Si te llevas el código a la BD, ya estás totalmente acoplado a esta. Ahí si nada que hacer. Si de antemano sabes que puedes terminar migrando a una BD diferente, de entrada evitaría los SP. Saludos Jhon!
tenía la misma duda, conocí hace poco el patrón criteria que va de la mano con orm, también encontré herramientas como querydsl y jooq, apenas las estoy estudiando pero creo que resuelven bien el problema, lo que si hay que tener en cuenta es la complejidad que necesitas manejar, nunca hay balas de plata
Excelente tema Manuel, en mi opinion, la logica del lado de cliente, debería ser solamente para "depurar o sanitizar" las entradas de datos con respecto a contenido de cada campo y como Maximo en una relación (ejemplo el tipo caso donde no hay una opción para el usuario y seleccionas "otro" y tienes que describir ese "otro")
@@ManuelZapata gracias Manuel por responder los comentarios. Estás construyendo con éxito una gran comunidad. Gracias a lo aprendido en tus videos he conseguido un mejor trabajo. Un saludo cordial desde La Paz, Bolivia
Sí, el acoplamiento de los controladores con la lógica de negocio es una de esas dependencias sutiles que se va complicando con el tiempo. Saludos Sergio!
Conoce mi curso de Arquitecturas Limpias
👉platzi.com/arquitecturaslimpias
Si no te tienes suscripción en Platzi, usa mi enlace de afiliado: platzi.com/l/manuelzapata/
La lógica del negocio (LN)
Es lo que la empresa tiene que hacer haya o no haya sistema
1. No amarres la LN a la bd
2. No poner la LN en el cliente
3. No poner LN en los controladores
4. Evita depender de terceros
5. Usa el patrón de diseño strategy
6. Usa el patrón de diseño template method
7. Falla lo más pronto posible
8. Evita devolver string como resultado
9. Conocer las capas de lógicas
🙌 Gracias por tu aporte Renso!
Que tipo de lógica debe ir en el cliente y que tipo de lógica debe ir en el servidor ufff esperare ese video
Super Julián! Parece que hay interés por el tema.
Manuel, en ese video me gustaría tener mayor claridad sobre por qué existe una lógica distinta en el cliente y otra en el servidor, ¿si la lógica es lo que hace siempre la empresa, no sería solo una?
Fabio, aquí estamos hablando de la lógica de negocio. También existe la lógica de presentación, que es la que maneja sí o sí la interfaz gráfica. Saludos!
@@ManuelZapata aaa, ya veo ya veo. Gracias!
x2
Lógica de Negocio = LN
Objetivos a cumplir de la empresa con o sin sistemas de información.
Recomendaciones:
- Separar LN de la base de datos.
- No meter la LN en los componentes UI.
- No meter la LN en los controladores.
- Evitar depender de terceros (APIS, Teconologías x como Gmail, etc...).
- Patrón de diseño STRATEGY recomendado (si aplica).
- Patrón de diseño TEMPLATE METHOD recomendado (si aplica).
- Seguir el principio "Fail Fast", o que el código falle lo más rápido posible, para reducir costos.
- La LN no debe devolver Strings como resultados (dificulta el desarrollo multi idioma en la UI y es frágil) | Usar Booleanos o tuplas.
- Conocer patrones específicos para la LN.
- Script de Transacción (muy usado).
- Modelo de Dominio.
- Módulo de Tabla.
- Capa de Servicios (muy usado).
Buen video Manuel, de hecho los consejos que das cuando se aplican ...se obtiene como resultado una gran modularizacion o encapsulamiento de código, y con ello aparece otro dilema para los devs, y es la organización o estructura de proyecto, que si bien muchos Frameworks ya te dan una orientación de cara este tema, en la gran mayoría de las veces eso no es suficiente y solo con la experiencia se logra entender la manera adecuada de organizar o estructurar los directorios y ficheros.
Me gustaría que hablaras de este tema de organización de proyecto, puesto que como arquitecto de software, posiblemente tienes mucho que aportarnos.
Manuel! Excelente video, si me interesaría mucho saber que debería ir en el front y en el backend.
Gracias por el feedback Ramiro! Parece que hay interés en el tema. Saludos!
Estoy de acuerdo contigo Ramiro. Saludos y buen video Manuel
gracias por la guia, por ahi vi un error de orotgrafia, liderzgo, capacidad de abstracción y
mentoría.en la palabra liderazgo
" 1. No amarres la LN a la bd
2. No poner la LN en el cliente
3. No poner LN en los controladores "
¿Y entonces donde ??? jeje , yo creo que va en mayor parte en el controlador y en menro parte solo conformando querys y ejecutandolas en los modelos.
En la vista nada
Al poner la LN en los controladores ...¿un determinado proveedor puede amarrar la solución a licencias de periféricos ?
Si la lógica de negoció no va en los componentes de Interface Gráfica y tampoco va en los Controladores entonces donde va ? No entendí si me puedes orientar
Estaría bien siempre del Controller comunicarme con un Facade y este a su ves los servicios? De esta manera no agrego la lógica en el controller y encapsulo todo en el Facade?
Lo que no me queda claro, es cómo organizar para quitarle responsabilidades a los controladores.
Que tipo de lógica debe ir en el cliente y que tipo de lógica debe ir en el servidor espero también ese video.
Parece que hay mucho interés! 🙌
Manuel hola. En MVC donde se debe programar la lógica de negocio si no es el controlador?
Excelente trabajo como siempre Manuel, Gracias por toda esa información.
6:26 Definitivamente SI!!!
"No depender de terceros". Que duro mas ? gmail o Webpack ?
Excelente vídeo
Visto en 03/03/2021
la logica de negocio seria la parte funcional del programa entonces la que hace alguna accion
Excelente contenido!! Gracias!
muy buenos videos, muy buen canal
Muy buen tema. Seria interesante tener claro que logia iría en tanto en el front como en el back, estare atento para cuado publiques el video.
Va Leandro! Gracias por la retroalimentación.
Saludos desde Brasil ! Um del más top canal del UA-cam! Sin duda!
Excelente explicación y muy buenas las sugerencias, saludos
Los que dieron Dislike al video, hacen páginas con wix...así que nada de esto les aplica lol 😂
Jejejej
Hijo buenas tardes, para mi negocio aplica la lógica de negocio
Por supuesto pá. Para todos los negocios aplica 😀
Gracias!!
Muy buen video! Una consulta, la lógica de negocio debería estar centralizada en una sola capa de la aplicación? Existe algún patrón que indique como hacer una correcta lógica de negocio ?
Revisa el consejo #9, Adrián. Ahí menciono patrones específicos para el dominio.
Concentrar la lógica de negocio en una sola capa? Yo creo que sería lo ideal, sin embargo he visto implementaciones donde se distribuye en varias partes.
Estuve peleando con un código por 1000 años y de lo dejé ahí para que se arregle solo, pero este vídeo me inspiró a levantarme, abrir el IDE y resolverlo. De corazón gracias!
Consejo #3. Entonces dónde pongo la lógica si no es en el controlador?
En los servicios, o incluso, en el dominio.
Hablando de amarres de la logica de negocio a los diferentes componentes seria interesante un video sobre Clean Architecture, que expone conceptos que ayudan al desacoplamiento de los componentes.
Muy buen aporte Gabriel. Te lo agradezco. Para allá vamos!
Muy buen video Manuel. Lo que no me quedó claro es que mencionas que la lógica no debe llevarse a cabo dentro del controlador del patrón MVC. Entonces donde debería si la idea es no pasárselo a la base de datos ni a la vista?
Gracias, a todo esto se pueden usar DSLs en la lógica de negocio? y que relación existe la lógica de negocio con BPMN?
Excelente video Manuel! Espero sigas haciendo este tipo de contenido y que el canal vaya creciendo. Saludos desde Argentina!
Gracias Nicolás! Aquí seguimos al frente del cañón. 🙌
Muchas gracias por el video Manuel, siempre claro y enriquecedor. Quede con ganas de ver el video que planteaste sobre:
Que tipo de lógica poner del lado del cliente y cual del servidor.
Ojala que lo puedas hacer. Muchas gracias.
Acabo de chequear antes de enviar el mensaje que lo hiciste. Genial!!!! lo veré.
Saludos desde Argentina!!!
Excelente video, saludos desde Perú, si me interesaría mucho saber que debería ir en el front y en el backend.
Hace tiempo que sigo tus vídeos Manuel. Muchas gracias por tu sabiduría y capacidad de comunicación
Al pendiente del vídeo de la lógica que debe ir en el cliente y servidor. Saludos y muy buen video
🙌
La mejor solución es con patrones de diseño que en el caso de la base de datos podemos usar el Factory Method para que nos traiga el objeto de tipo Connection de JPA independientemente del driver que se utilice, y también tenemos que conocer lo que conoce como inyección de dependencias para hacer sistemas con un bajo acoplamiento
6:24
Existe ya un vídeo explicando qué tipo de lógica debe ir en el cliente y en el servidor?
increaible video me encanta este canal bendiciones
Excelente información! Gracias Manuel, muy interesante la aplicación de patrones y la separación de la lógica de negocio, no había pensado en las tuples 👌🏾
Buenas tardes, arquitecto.
No soy de escribir en tu canal, solo felicitarte de tomar tu tiempo de compartir tus conocimientos valiosos sobre software.
Te digo que me gustaría que en algun video explicases la capa de servicio, lo que conlleva y la diferencia con la capa de negocio, que suele estar en el dominio segun ddd.
Gracias
Hola Maximiliano! Gracias por la recomendación Ya la anoté en mis lista de futuros temas.
Muchas gracias, tus consejos siempre me ayudan.
Me quede con la idea de que tiene un BtnGuardar y el el evento click... ¿como lo harías, podrías darme un ejemplo? Para terminar de aterrizar la idea.
Saludos desde México.
Hola Viktor! 👋 Se puede hacer de varias formas. Si ves que tienes mezclada la interfaz gráfica con la lógica de negocio en el mismo archivo, solo sácala a un archivo/clase aparte y llama funciones de la lógica desde los manejadores de eventos. Saludos!
Hola Manuel, excelente video como siempre.
Tengo un par de preguntas en las que me gustaria conocer sus ideas.
Con respecto al punto 1, precisamente en estos días he estado leyendo mucho sobre el repository patterm y he visto muchos artículos donde lo califican de anti patrón y de sobre abstracción si se usa con un ORM como Entity Framework por ejemplo, esto porque EF ya implementa el patrón, el DbContext es un unit of work y cada DbSet es un repositorio en si mismo. ¿Qué opinión tiene al respecto?.
Lo segundo va un poco en relación a lo anterior, ¿me gustaría saber cuál considera una buena aproximación a una arquitectura en capas para un desarrollo empresarial? La aproximación a la que estoy llegando en este momento es la siguiente:
Una capa Core con abstracciones de la logica del negocio (interfaces), abstracciones de los repositorios en caso de usarse y no sé si los modelos deberian ir aquí.
Una capa a la que llamo de servicios o de implementación de lógica de negocio en la que implemento las interfaces de la capa anterior (aquí materializo los casos de uso que describí en las interfaces de la capa anterior).
Capa de presentación.
Espero esto no sea muy largo de leer.
Gracias y siga así con el canal.
Hola Luis!
Efectivamente, el repository y el ORM se solapan de alguna manera. No sé si llegar al punto de llamarlo antipatrón, pero ciertamente hay que saber manejar los 2 en conjunto.
En cuanto a lo segundo, creo que vamos por enfoque muy Clean Architecture o Arquitectura Hexagonal. Quizá ya estás familiarizado con ambas arquitecturas, pero creo que estas te pueden dar una idea para validar tu enfoque.
Saludos!
Buena introducción me llamó la atención el módulo de tabla, es diferente a reglas de negocio? donde puedo profundizar en esos patrones?
Son diferentes. Puedes profundizar en este libro de Martin Fowler: amzn.to/3kvLJJI
O en mi curso de patrones de arquitectura: cursos.manuelzapata.co/inscripcion-curso-practico-patrones-arquitectura/
También quedo atento al video sobre que tipo de lógica debe ir en donde! Jeje. Y adicional... o quizás sea tema de ese video; es necesario hacer validaciones tanto en el front como en el back?
Buena pregunta esa, Diego. La tendré en cuenta.
¿Que hay sobre tener un rules engine?
Hola Alfonso. En escenarios complejos de negocio se van volviendo necesarios. No los traje a mención en este vídeo por ser algo más especializado que en aplicaciones más sencillas no se necesita. Saludos!
@@likecomtic-arquitectoSoftware gracias le daré un vistazo 👍🏻
Que buen ejemplo eso de que el Controlador es el 10 del equipo! Nunca se me olvidará. Gracias!
Que bacano. Saludos Diego!
Excelente vídeo. Me aclaraste muchas dudas. Y sí, me interesa que realices el vídeo de que lógica de de ir tanto en cliente como en servidor. También, me gustaría que hicieras un vídeo sobre Model Domain, veo que es usado para que le puedas explicar a una persona ajena al software y sin conocimientos de desarrollo para que entienda como funciona tu sistema. Saludos.
Con todo gusto Cristian! Gracias por tu retroalimentación en cuanto a hacer un vídeo de cómo separar la lógica. Saludos!
Viejo Manuel, no te olvides de hacer el otro vídeo aclarando que debe ir en la lógica del cliente y la del servidor por favor.
Vendrá el video William!
Excelente video Manuel, tus videos me han ayudado a desarrollarme mejor :D
Con mucho gusto, Dave!
No entendía que era logica de negocio hasta este video! Gracias
Genial Renny! 🙌
Gracias por el video! Si no pongo la lógica de negocio en el controlador ni en UI, dónde lo pondría? Saludos :)
En su propia capa, Ramiro. Puedes tener una capa de lógica de negocio. Saludos!
Me encanto el. Video, lo aplicaré a mis servicios Rest
Genial!
Estupendo video, genial la idea del video de logica en el cliente vs logica en el servidor, saludos
🙌
hola, cuando haces un curso de LINQ?
Hola Karin. Te agradezco la sugerencia. No creo que lo haga. Mi canal va por una línea diferente. Pero, nuestro canal amigo hdeleon.net fijo tiene contenido de LINQ: ua-cam.com/channels/DUdeFslCNoM29MAlZOfdWQ.html
6:25 Me interesa.
Existe ya ese vídeo?
Seguro ya viste el video, pero en todo caso te lo dejo: ua-cam.com/video/SPmbxvvT7Aw/v-deo.html
Fantástico, por fin un buen canal en español, muchas gracias Manuel, te ganaste un suscriptor y muchos likes =)
Esperaré el video de logica en el cliente y en el servidor !!!
Gracias Yuri! Ya está video disponible: ua-cam.com/video/SPmbxvvT7Aw/v-deo.html
@@ManuelZapata Perfecto! Muchas gracias!
Buen video. Sin embargo, tengo dos observaciones con respecto al cuarto punto. La primera es que el ejemplo de Gmail no es muy ilustrador porque finalmente uno no escribe lógica para Gmail específicamente, si no usando el protocolo SMTP, por lo que el proveedor si es restrictivo se puede cambiar por otro sin ningún problema. La segunda observación es que el concepto no es que no se deba depender de terceros. Dices que idealmente no depender de terceros, lo que puede implicar, en el ejemplo, construir mi propio sistema de mensajería y tampoco es la idea. Lo correcto es que en la lógica de negocio no se escriban rutinas que dependan de terceros específicos y abstraer esas dependencias en otras capas de forma tal que se puedan reemplazar sin afectar la lógica de negocio. Así las cosas, este punto se puede ejemplificar mejor con el caso del primer punto: no creo una dependencia frente a un motor de bases de datos específico en mi lógica de negocio sino que lo abstraigo a otra capa y puedo reemplazar en esa otra capa, o en otra implementación de esa capa, el motor en un futuro sin afectar la lógica de negocio.
Gracias por la retroalimentación Jhonny. Tienes toda la razón. El cuarto punto se pudo haber explicado de manera más clara, cómo lo describes.
Espero que aún así, se haya podido transmitir el mensaje. Saludos!
@@ManuelZapata Sí, se entienden todos los temas con total claridad. Gracias Manuel por compartirlo.
Hola, excelente video, yo tengo una duda con el patron repository, a veces se necesitan hacer consultas complejas a la BD, y veo que las hacen en stores procedures en la BD, como pasarlas a un patron repository y que pueda yo si necesito cambiar luego mi BD de sql por ejemplo a mongo qie esto no sea traumatico, gracias y saludos Manuel.
Esa es una desventaja de usar procedimientos almacenados. Si te llevas el código a la BD, ya estás totalmente acoplado a esta. Ahí si nada que hacer.
Si de antemano sabes que puedes terminar migrando a una BD diferente, de entrada evitaría los SP. Saludos Jhon!
tenía la misma duda, conocí hace poco el patrón criteria que va de la mano con orm, también encontré herramientas como querydsl y jooq, apenas las estoy estudiando pero creo que resuelven bien el problema, lo que si hay que tener en cuenta es la complejidad que necesitas manejar, nunca hay balas de plata
Excelente tema Manuel, en mi opinion, la logica del lado de cliente, debería ser solamente para "depurar o sanitizar" las entradas de datos con respecto a contenido de cada campo y como Maximo en una relación (ejemplo el tipo caso donde no hay una opción para el usuario y seleccionas "otro" y tienes que describir ese "otro")
Coincido contigo, Jose Luis! Cuando haga el video, profundizaré en las validaciones.
@@ManuelZapata gracias Manuel por responder los comentarios. Estás construyendo con éxito una gran comunidad. Gracias a lo aprendido en tus videos he conseguido un mejor trabajo. Un saludo cordial desde La Paz, Bolivia
Excelente, lo de los controladores no lo había considerado muchas gracias
@@likecomtic-arquitectoSoftware gracias lo reviso
Sí, el acoplamiento de los controladores con la lógica de negocio es una de esas dependencias sutiles que se va complicando con el tiempo. Saludos Sergio!
Genial!!!!!!!
🙌