Monolitos modulares | CREA aplicaciones monolíticas con esto ANTES de usar microservicios

[@cmsalvado]

Excelente video, dejo una cita de Robert C. Martin (Tio Bob): "Los microservicios no son una arquitectura, son una estrategia de despliegue. El desacoplamiento y la división podran (y deberían) lograrse independientemente de si se impone el límite de servicio."

[@ManuelZapata]

Excelente cita, Christian! Si lograramos desarrollar con ese nivel de desacoplamiento, pasar a microservicios debería ser sencillo.

[@JosuFeijoo]

@@ManuelZapata Se puede. Antes de los micro servicios , hace ya años, todo lo que montaba era modular sin dependencias. El problema es que es difícil mantener esa disciplina en equipos grandes. Incluso con los micro servicios a veces se escapan cosas y hay miembros del equipo que se saltan esa separación. Yo he conseguido hacer una arquitectura modular en clipper y Delphi ( ya di pistas de mi edad 😂 )

[@elbertjosesalasbrochero6318]

Conclusion son fragmentaciones de una aplicación completa.

[@danielhuaman274]

quien tendria la razon? tu tio bob o martin fowler? segun Martin Fowler dijo lo siguiente: La Arquitectura de Microservicios es una "forma particular de diseñar aplicaciones de software como conjuntos de servicios desplegables de forma independiente". mas bien no seria un estilo arquitectonico?

[@cristiancamilosanchezardil9730]

Un companero de trabajo me envio este video, fue lo mejor del dia. Gracias Manuel excelente video!

[@yesidays]

Excelente video Manuel, leí por encima pero ahora con tu video me queda todo muy claro, gracias por compartir

[@ManuelZapata]

Gracias Yesi por pasarte por acá y por compartir el video!

[@Coderoll]

Me parece una estrategia muy inteligente que la aplicación vaya marcando la evolución de la arquitectura. En los últimos años he hecho varias aplicaciones nuevas y no he necesitado los microservicios, no es resistencia al cambio simplemente las modas no me apantallan. Saludos!

[@ManuelZapata]

Muy sabio ese enfoque @CodeRoll. Seguramente cuando llegue la necesidad, aplicarás microservicios.

[@samueldavidgomezramos7880]

Uy considerar que los microservicios son moda es una afirmación muy atrevida.

[@martingonzalez4648]

CodeRoll, los microservicios no son una moda, es una forma de desarrollo para la evolucion del software desacoplada y facil de desplegar , yo llevo varios años desarrollandolos y dan una gran cantidad de facilidad a la hora del desarrollo y sobre todo del despliegue, permite esa independencia de modulos que de otra manera es mas complicada y encima si agregamos que los modulos de aplicaciones pueden tener diferentes evoluciones ...

[@Coderoll]

Vale, igual me la bañe con eso de las modas. Aprovechando, tu que tienes experiencia en microservicios ¿Cuándo no los usarías? ¿esto de los monolitos modulares te hacen sentido o te vas directo al microservicio? Parto de la idea que no hay arquitecturas ni buenas ni malas, todo depende del contexto y en mi contexto no los he necesitado al parecer desarrollo monolitos muy buenos jejeje. Saludos!

[@martingonzalez4648]

@@Coderoll Como bien tu dices no hay ni buenas ni malas, y como has mencionado las arquitecturas hay que usarlas en su contexto correcto, no siempre he desarrollado ni desarrollo microservicios hay veces que es mas practico una arqutiectura monolita y no hay ningun problema, yo las monolitas las usaria en pequeñas aplicaciones y que no tengan mucha evolucion en el tiempo. Pero si realmenten es una aplicacion que tiene una evolucion continua es preferible usar los micros, por ejemplo una api de gestion, usaria un proyecto monolito para las maestras esas poco tiene de evolucion, pero en el negocio si usaria microservicios Un saludo

[@andrair88]

Me gusto mucho el video, efectivamente pienso en monolitos y creo que para usar microservicios debe haber una experiencia- necesidad puntual y enorme.

[@dhalachian]

Los microservicios no aparecieron como consecuencia de una mala arquitectura monolítica, ni del mal uso de patrones de diseño, los microservicios son la consecuencia de la necesidad de balancear las diferentes cargas de la aplicación y de garantizar hasta cierto punto la resiliencia del sistema. La parte positiva que muchos desarrolladores ven es que pueden trabajar orientados a contratos donde cada microservicio sería una caja negra para el que no lo mantenga. Uno de los principales problemas vienen desde el punto transaccional, cuando más de un microservicio toma parte en la misma transacción, garantizar la consistencia y atomicidad se vuelve complicado. Otro gran problema viene con la mantenibilidad del código, al ser un desarrollo orientado a un contrato no tenemos la ventaja del tipado fuerte del compilador, cualquier cambio inocente en un nombre de una variable a consumir puede llevar a que el sistema no funcione, o peor, que funcione de forma errónea. Otros elementos a tener en cuenta son: hay que cambiar el proceso de cómo se hacen las liberaciones, como se hace el monitoreo y traceo de errores, como preparar datos válidos para las diferentes tipos de pruebas. Para decidirse por la arquitectura de microservicios debemos tener razones sólidas porque implica una inversión en tiempo, hardware y conocimiento.

[@ManuelZapata]

Lo has descrito muy bien, Denys. Gracias!!

[@aquilesviza5550]

Muchas gracias por esta respuesta tan completa. Solo me queda una duda, ¿A que te refieres con la consideración del "cómo se hacen las liberaciones"? No se si te refieres a bajar instancias de los microservicios, o qué tipo de recurso liberar. Pese a eso, tu comentario me sirve bastante :)

[@cesarleon1892]

Excelente video gracias por compartir tus conocimientos Manuel.

[@pedroamparo6727]

Excelente contenido el que brinda Manuel, llevemos este canal a otro nivel!!!!

[@ManuelZapata]

Al siguiente nivel! 📈

[@lilianrgg]

Excelente video, explica super bien gracias por compartir sus conocimientos.

[@ManuelZapata]

Con todo gusto, Lilián!

[@jesuspache9365]

Excelente explicación.

[@moviedomof]

muy bueno.. a la larga se reinventan las cosas con nombres y detalles diferentes.. Esto de separar en capas y proyectos ya se hacía en 2003 cuando vino .net . Lo hacíamos con otras arquitecturas más acopladas como remoting web services etc no existía mucho sobre APIs REST y menos Microservicios pero a grosos modos es una arquitectura super usada desde hace 20 años

[@sebastianvalenciacarvajal9694]

Que explicación tan excelente, muchas gracias

[@thaeronmorales8408]

Muchas gracias amigo, saludos desde venezuela... Actualmente estoy incursionando en un framework de Typescript llamado NestJS y su diseno de arquitectura es completamente modular. Esto complementa con mi proceso de aprendizaje

[@ManuelZapata]

Genial Thaeron. Saludos desde Colombia!

[@josereynelchauxperez947]

Excelente material, muchas gracias !!!

[@MrSfaundez]

Muy interesante Manuel muchas gracias por explicarlo tan claramente.

[@lucashenry5380]

Buen video manuel, para complementar, cuando se utiliza una base de datos por monolitos modular, ya estas aplicando un patron de los microservicios y por lo que veo lo que se esta aplicando aqui es el desacople por capacidades de negocio. un microservicio no necesariamiente debe ser 'micro', el tamaño del MS va ligado con la parte del negocio que quiere cubrir.

[@rurouniize]

Muy buen tema, me recordó que Zend Framework 1.0 + ya se trabajaba la arquitectura modular y para Zend Framework (2 y 3) ahora llamado Laminas su punto fuerte poder separar en modulos la aplicación. Y como bien mencionas al interior del modulo se aplica la arquitectura que más convienga, en Laravel también se podría usar implementanto la separación por package que sirven para extender las funciones.

[@agu160579]

Totalmente de acuerdo. El problema de hoy día es que hay personas en puestos de decisión que realmente no entienden la programación. Como tú bien dices, se mueven por modas. Hace falta una revolución en el sector de la programación, donde los programadores no se limiten a tirar líneas de código si no que vean una aplicación como algo vivo, que crecerá y que no sabemos por donde lo hará. Esto debe hacer al programador tener un poquito más de formación sobre las tecnologías (si bien es cierto que no hay mejor ni peor, sino que dependerá de la finalidad del programa) También es importante que nuestro código esté modularizado, de modo que la lógica de negocio no sea un galimatías para un posible programador que ocupe nuestro puesto a futuro. En mi caso (y no digo que sea la mejor forma), uso .NET con EF y MVC 4 y conectada al dominio. Pero la aplicación es una especie de megaprograma modularizado, con secciones. Es decir, tengo una base monolítica que solo te lleva al login. Una vez te logueas ya tienes un menú lateral con todas las secciones o programas con su código standalone (Modelo de datos, con su controlador con sus vistas) y todo independiente de todas las demás secciones además como está conectada al dominio puedes gestionar fácilmente los permisos a las secciones mediante asignación de grupos en el controlador de dominio. Obviamente esto te hará usar métodos parecidos por no decir idénticos por lo que tiene un poco más de trabajo, pero es ROBUSTA, escalable y fácilmente entendible para otro programador. Éste programa nació como una idea en el 2017 y hoy día es una parte muy importante de la empresa. Sigue así Manuel Zapata, tienes la visión clara de un buen programador!

[@totobol86]

Me parece interesante y nosotros estamos pasando por un proceso conceptual de Modularización de un monolito, para luego ir a Microservicios. Creo que es el mejor path de migración para romper el monolito. Saludos

[@ManuelZapata]

Es un buen path. Saludos Javier!

[@oddocid9734]

Esto es buenísimo!!!

[@luispastendev]

Concuerdo contigo, el problema la mayor parte de las veces es el diseño de las aplicaciones no tanto la arquitectura, inclusive si tienes un monolito bien hecho si alguna ves por escalabilidad requieres mudar tu aplicación a microservicios es muy fácil separarlos, cada ves trato de pensar mas en como resolver mis problemas en code modules que aunque parezca algo complejo al final favorece muchisimo es como si programaras paquetes y los subieras a packagist en cualquier momento los descargas con composer y los implementas en el proyecto que necesites con solo modificar algunos ficheros de configuración y lanzar migraciones. buen video gracias Manuel!

[@ciscobautista5033]

Excelente video Manuel, todo me queda muy claro en estos conceptos que no los tenia tan claros, Gracias!

[@ManuelZapata]

Con todo gusto!

[@davisayus9643]

Excelente explicación, quiero contarte que sin saber estaba implementa esta arquitectura, pero solo lo hice por organización ahora con este video voy a independizar un poco más, sería bueno un ejemplo de comunicación de esta arquitectura 👍🏼

[@feyaluciano]

Muy interesante Manuel, se puede decir entonces que de esta forma, si se relaliza un simple cambio, hay que deployar todo el monolito modular no? como si de un monolito normal se tratara.

[@ecastrojimenez]

Excelente video, felicidades!!... desde mi vida laboral he venido comentando que no se debe escoger la arquitectura de una solución basado al modismo, eso es un gran error y con charlas o actividades con proveedores, se vuelve un punto de controversia. Esta es una buena opción que se debe analizar, otra opción válida. Agradecería mucho que nos compartas el código para conocer de fondo la propuesta. Gracias y saludos!!

[@ManuelZapata]

De eso se trata. De conocer opciones y saber cuándo es conveniente usar una o otra. Ya con eso vamos ganando. En la descripción del vídeo está el enlace al repositorio.

[@kantyDarius]

Me acabo de dar cuenta que estuve desarrollando monolitos modulares sin darme cuenta 😂. Buen vídeo 👏🤘.

[@UskoKruM2010]

Muy interesante tema, amigo Manuel, comenzando a escuchartee... 👋🏻

[@ManuelZapata]

Gracias Oscar por pasarte por aquí!

[@carlosjosepertuzarroyave1559]

Estimado Manuel y comunidad. No entiendo el tema de los despliegues para este tipo de arquitectura, si tengo dos módulos, facturas y documentos. Requiero realizar un ajuste sobre documentos, como despliego sobre el modulo documentos sin afectar la disponibilidad del modulo facturas? si todo esta en un monolito aunque sea modular? Agradezco sus aportes.

[@walterrodriguez2696]

Excelente video!. y ahora en 2022 Modular monolith ya está en "Early majority", significa que ha tenido más adopción?

[@misakyanzye4269]

Si necesito hacer un reporte con datos de modulos dependientes entre si, como sería el flujo de las peticiones?. Es decir, mi reporte inicia con datos del modulo A y por cada registro necesito su detalle que existe en el modulo B entonces como diseño el flujo de peticiones hacia el modulo B para no hacer algo así como un N+1 ?. Alguien sabe como se resuelve ese tema? ya que por lo que veo tendria que respetar el patrón de arquitectura y hacer solicitudes entre APIs

[@armandomen2944]

Que buen video manuel, yo no sabia que microservicios eran mas de moda, muchas gracias por compartir el repositorio de Kamil. Muy informativo este video.

[@ManuelZapata]

Ha sido con todo gusto Armando!

[@ÁngelManuelBonillaHuesca]

En un monolito modular, podemos usar diferentes stacks y lenguajes para cada modulo o si esto es un requerimiento es mejor iniciar desde microservicios? Saludos

[@cedaesca19]

Excelente, me encantan los temas de arquitectura de software. Tienes un nuevo suscriptor :)

[@ManuelZapata]

Bienvenido César!

[@Murzbul]

Me hizo recordar bastante a lo que se hace con nx monorepo. Buen video!

[@ManuelZapata]

Gracias Nathan!

[@giovannyavila8105]

Que chévere hacia esto sin darme cuenta en Laravel , cada módulo expone un service provider e inyecta interfaces en lugar de objetos concretos y los iba creando por separando e instalando vía composer como una dependencia de Laravel

[@ManuelZapata]

Excelente! No estoy familiarizado con Laravel.

[@orlandomorales509]

Buen video, microservicios otro legacy hell para los proximos años, a ver como queda ahora estos monolitos modulares, mas de lo mismo renombrado

[@ManuelZapata]

Así es. No necesariamente las tendencias son cosas realmente nuevas. De hecho, hay personas que dicen los microservicios tampoco eran nada nuevo. Eran sencillamente una variante de SOA con nuevo nombre.

[@javiopakan2]

Saludos, gracias y Bendiciones..... Estuve revisando el proyecto que mencionas aqui y veo que el lo mantiene actualizado!!!... algo me llamo la atencion, es que revise el proyecto y en ninguna parte del proyecto el realiza validaciones de que no le manden un correo como string en blanco, o algo asi, desde el API, luego a la aplicacion de un modulo, hasta el dominio de ese modulo, no existe ni una validacion de que los datos que se envian estan bien.... me pregunto si hizo eso por ahorrar tiempo o me estoy perdiendo de algo, talvez podrias revisar su repositorio y comparta tu opinion... de nuevo gracias y Bendiciones!!!

[@felipellc5495]

gracias por el aporte! ..unos comentarios..es importante mencionar que para saltar a una arquitectura microservicios se requiere hacer una buena descomposición funcional, y creo que eso también aplicaría para los monolitos modulares, aplicando DDD por ejemplo.. mencionaste que se puede aplicar la arquitectura hexagonal para implementar un módulo monolítico, pero entendería que ya no sería una hexagonal como tal porque estarías integrando la capa de presentación a la arquitectura lógica, y eso es justamente lo que una arquitectura hexagonal no debe hacer. Otro tema importante es que en la práctica si todo el código fuente está en un solo proyecto y se maneja los módulos como una división puramente lógica (paquetes en java por ejemplo), se hace dificil controlar que un programador no acceda a la implementación de la api publica de otro módulo.. cosa que un microservicio se puede controlar fácilmente... saludos.

[@ManuelZapata]

Gracias por tu aporte, Felipe. Hay formas de organizar el código que van a ayudar más al encapsulamiento que otros. La idea de que puedas implementar una arquitectura hexagonal (o cualquier otra) en un módulo es un poco para mostrar la independencia de los módulos.

[@alvarofuenzalida2753]

Muy buen video Manuel, saludos desde Chile.

[@ManuelZapata]

Saludos Alvaro. Gracias!

[@rusia18rusia65]

Gracias por los videos!

[@ManuelZapata]

💪

[@FidgoBlogspot]

Me gustó, nuevo sub

[@ManuelZapata]

Bienvenido por estos lados.

[@edwardalexanderpinedamarin429]

Excelente video. Gracias por compartir !

[@ManuelZapata]

Mil gracias por esas palabras Edward!

[@cesarpuma7862]

Hola Manuel, muy interesante el video. Según lo que explicabas en el minuto 9:35 . Si un módulo necesita algo de una tabla que esta bajo el control de otro módulo , este no debería consultar directamente a la tabla. Si no , respetar y consultarlo por ese módulo . Así lo entendí y que me parece buena práctica, porque si se modifica algo en esa tabla , solo se modificaría un módulo. Pero en el ejemplo de Kamil, veo que crea tablas por Modulo (minuto 13:13) , con el mismo nombre, similares en su estructura (por no decir iguales). No se si entendí mal :/

[@sloventblake7990]

exclente muchas gracias!

[@ManuelZapata]

Con gusto, Diana!

[@yamillanz6398]

Excelente...Yo buscaba el nombre de lo que hacemos en mi empresa y es este....

[@ManuelZapata]

Genial! 🙌

[@MauricioMurielDev]

Buen video Manuel, ilustrativo material, gracias.

[@ManuelZapata]

Con todo gusto Mauricio!

[@ceorcham]

Excelente explicación, has visto Django? Esa es exactamente la forma en cómo se plantean los módulos, que allí se llaman aplicaciones ( en especial respecto de la base de datos)

[@ManuelZapata]

Genial lo que me cuentas Cesar. He escuchado de Django, pero nunca lo he usado. Qué tan fácil será con Django separar luego esos módulos en servicios independientes?

[@whitmanbohorquez184]

@@ManuelZapata Es bastante facil, doy fe de eso

[@f3rch0c]

Muy buen video. Tengo una consulta. Si tengo un módulo de facturación de una tienda de abarrotes y otro módulo para administrar los artículos la descripción del artículo que va en la factura la debería obtener desde el módulo de artículos, que método recomendarías?

[@idcmardelplata]

Se me hace bastante familiar esta arquitectura, sobretodo porque programo en elixir y ahí se usan este tipo de arquitecturas.

[@ManuelZapata]

Buenísimo! La idea no es tan "novedosa". Es solo que ya se le dio un nombre y se le está haciendo más difusión.

[@maikolcucunuba2252]

¿Manuel se podría decir entonces que esta es una arquitectura por servicios?

[@williandavidlopezsanchez8331]

hola Manuel, muchas gracias por el video. en donde puedo ver un tutorial o libro que sea practico para .net core sobre el monolito modular en capas

[@ManuelZapata]

Quizá esta serie de artículos te puede ser útil. www.kamilgrzybek.com/design/modular-monolith-primer/

[@ivanherrera6928]

Genial tu contenido.

[@ManuelZapata]

Gracias Ivan!

[@EduardoPatricioRoseroVaca]

Como quedan las tablas que son comunes a todo los módulos tales como tabla de países, tablas de bitácoras de acceso al sistema quien posee el control de estas tablas en un sistema monolitico

[@leonardodanielzaragozamata4836]

Buena pregunta, aún no entiendo mucho, pero de acuerdo con el vídeo, esta info debería pertenecer a un microservicio o monolito y consultarse exclusivamente por una API.

[@jruitti]

Siguiendo la línea de “Software is meant to be soft” de Martin Fowler, la implementación del software debería poder variar de estrategia. Si es costoso, entonces podríamos haber diseñado mal la arquitectura. Muy buen video! Gracias!

[@ManuelZapata]

Gracias por tu aporte, Javier!

[@elbertjosesalasbrochero6318]

Lo bueno de esto es que así se puede crear una aplicación rápido si , se reparte el trabajo por módulos a cada programador.

[@videovideo166]

Me supo a algo que sabemos de perogrullo o no? Como q hacer submodulos es lo minimo q deberiamos hacer en cualquier situacion. o me equivoco?

[@Magistrado1914]

Excelente vídeo Visto en 08/11/2020

[@ManuelZapata]

🙌

[@johncerpa3782]

Buen vídeo

[@ManuelZapata]

Gracias!

[@andresnator]

Interesante opción para cuando existe esa incertidumbre de escalabilidad

[@ManuelZapata]

Exactamente. Puede ser que al final nunca se escale, y así no se desperdicia el esfuerzo de desarrollar microservicios.

[@andresnator]

@@ManuelZapata Que suele ser en ocasiones agotador

[@williandavidlopezsanchez8331]

Buenas noches, buen video. Una pregunta esos módulos es lo mismo que se conoce en clean arquitecture como bounded context o son diferentes conceptos. Gracias

[@ManuelZapata]

Si pensamos en que la separación de los módulos se hace por funcionalidad, tiene mucha relación con los bounded context.

[@andrescolina8288]

Al escuchar esto describe lo que es angular.

[@edwinspiredev4930]

Excelente.

[@ManuelZapata]

Gracias!

[@josemanuellucasbarrera3709]

Esto es como Liferay creo?

[@jhonnyjamifernandez447]

Buen video, podrías hablar de osgi vs microservicios, gracias

[@ManuelZapata]

Gracias por la sugerencia, Jhonny. Lo anoté como idea para futuros videos.

[@samueldavidgomezramos7880]

Cómo juega la escalabilidad en esta arquitectura? Si uno de esos módulos requiere escalar 3 nodos por temas de demanda en un día o una hora específica, todo el monolito tiene que escalar?

[@ManuelZapata]

Así es. Todo el monolito tiene que escalar. Esa es y seguirá siendo una desventaja de cualquier monolito.

[@SimaDamian]

Excelente! Tengo una duda. En este proyecto de ejemplo la comunicacion entre modulos lo hace bajo eventos (usa MediatR). Y es practicamente 4 microservicios pero sin implementar la capa de Aplicacion con técnicas de comunicacion entre procesos. Por tanto la unica ventaja vs Microservicios es en cuanto a infraestructura IPC. No me queda claro cual es la ventaja real vs 4 microservicos para este ejemplo. Gracias, Saludos

[@hermanolazcano]

Hola, es relativo, me llama la atención una frase "...donde todo esta junto y todo es más fácil de desarrollar, siendo un monolito..." (Min.3:22) , para mi eso no es cierto, en nuestro caso usando Java Spring Cloud Microservices, se ha logrado una experiencia mejor al desarrollo monolítico, mejor control del tiempo, presupuesto y recursos. Es relativo ya que si hablamos de un sistema MVC construído por solo un equipo, compuesto por seis desarrolladores, aún cuando tengas una herramienta de integración como TFS u otra, si escalas ese proyecto a cuatro equipos ubicas tres de esos equipos en países distintos, contabilizando 50 desarrolladores al final, la complejidad es bastante mayor, lo monolítico me parece que se va mantener "simple" dependiendo de la escala, en su lugar la el diseño orientado a microservicio, permite generar un proyecto distribuído desde el inicio, con 1..n células y con una integración continua que se puede automatizar garantizando despliegues optimos. Por lo demás después de ver el video, me parece que es no plantea nada nuevo, es como forzar la arquitectura monolitica a trabajar similar a un diseño de micro servicio, por otro lado la organización que muestras en el proyecto de ejemplo es simplemente DDD, al final depende mucho en como lo ilustras, cómo lo prsentas y organizas en el proyecto, pero nuevo? Como concepto? No, no parece, mas bien un "Revamp" o "Upgrade" que en lo personal he visto muchas veces. De hecho el proyecto de ejemplo mostrado, en micro servicio probablemente se puede armar con tres microservicios y un "broker" (Kafka) y un Api Gateway que ni siquiera debe saber de estos microservicios ya que los puede localizar automáticamente, evitando mucha configuración y proceso de DI. Entre eso y DDD me quedo con DDD o un buen proyecto MVC armado dividido en varias API's y orquestadas por un administrador de procesos y todo ello sigue siendo más pesao que simplemente realizar un proyecto de mciroservicio en NODE JS o JAVA e incluso .NET. Saludos, buena iniciativa!

[@ManuelZapata]

Ahí está el debate. Es una tendencia que se está discutiendo en la industria. Ya veremos si se adopta. Y eso es lo curioso. Las tendencias no necesariamente son ideas nuevas. A veces solo dan nombre a algo que no lo tenia, pero ya lo haciamos. Los mismos microservicios: hay gente que considera que no eran nada nuevo en su momento, y solo era una forma particular de hacer SOA. Lo de la escalabilidad es algo incierto, dependendiendo del proyecto. Hay proyectos que nunca crecen (por mas que el negocio quiera que crezcan). En esa incertidumbre es que creo que puede funcionar esa arquitectura. Por otro lado, creo que es bueno nunca olvidar el principio KISS y no hacer sobre ingeniería (especialmente si hay incertidumbre). Gracias por tu aporte, Juan.

[@Unknown971]

Tengo que hacer mi proyecto de tesis para el año que viene, y soy el unico que haria todo usando mysql con nodejs y angular (una aplicacion para gestion de pedidos, carta, etc para un restaurante). ¿Me recomiendas esta arquitectura? Estaba pensando en una de micro servicios, pero ya se me puede complicar una monolitica, y estando solo no se si vale la pena ya que le retrasaria mucho

[@ManuelZapata]

El monolito modular es una excelente forma de empezar. Lo bueno es que te deja la puerta abierta cuando se requieran los microservicios.

[@Unknown971]

@@ManuelZapata Excelente, me pondre a investigar mas a fondo durante este verano sobre como implementar este patron de arquitectura en mi proyecto. Seguramente con una base de datos con varios esquemas.

[@marlonconrado6136]

Muy buen video, pero me queda una duda pendiente y es ¿Cuándo sé que debo pasar a Microservicios?

[@designanimation]

A qué se refieren a la capa de presentación? Gracias

[@ManuelZapata]

Capa de presentación es contra la que interactua un usuario. Ejemplo: una página, un formulario en una aplicación de escritorio.

[@designanimation]

@@ManuelZapata gracias Manu!

[@dmsanz_youtube]

Alguna técnica para tener múltiples soluciones para no tener una única solución para decenas de proyectos?

[@giancarloaparicio5841]

Genial... 👍 Muy interesante el video 😁😁😁

[@ManuelZapata]

Gracias Giancarlo!

[@benjaminlizarraga7926]

Hola! me topé con tu canal y me encanta, tengo una pregunta, que sucede en el caso de las transacciones que involucren mas de un modulo? se aplica patrones de microservicios?

[@ldiego08]

En una arquitectura monolítica modular es bueno tener un canal de comunicación entre módulos para abstraer lo más posible. Una forma de hacerlo es con el patrón CQRS (que menciona Manuel al final del video) que define un service bus y eventos. Es parecido a queues.

[@daviscruz1101]

Excelente vídeo Manuel, cuando un vídeo sobre DDD 😁?

[@ManuelZapata]

Yo sé. Ese es uno de los pendientes en el canal.

[@claudiomnec]

Excelente explicación. ¿Es recomendable utilizar integridad referencial entre módulos? Puesto que si separamos los módulos por bases de datos perdemos la integridad referencial (en el caso de utilizar modelos relacionales).

[@ManuelZapata]

Yo creo que sí. Yo mantendría siempre la integridad referencial, hasta que la separación no me lo permita.

[@daniveloper]

El API también se podría llegar a modular? Cómo se llegaría a comunicar un módulo con otro módulo, es decir, a partir de qué capa?

[@ManuelZapata]

Te refieres a un API REST? Realmente la arquitectura no entra en mayores detalles en el punto en el cual se hace la comunicación con otro módulo. Esto dependerá de la organización interna de cada móulo.

[@daniveloper]

@@ManuelZapata entonces podría ser comunicación entre endpoints por medio de http o por medio de las librerías internas, no?

[@cristiandavidippolito]

Si están trabajando en JS / TS pueden revisar un framework llamado NESTJS y facilita este diseño modular, además tienen un curso oficial muy bueno.

[@ManuelZapata]

Buenísimo el dato. Gracias por compartilo, Cristian!

[@marioalejandromendez5051]

Hola Manuel, Excelente video. Te quería preguntar si en este tema de monolitos modulares podríamos meter a tecnologías de java como OSGI implementando frameworks como apache karaf

[@ManuelZapata]

Con OSGI no estoy familiarizado Mario, entonces no podría darte una opinión. Lo que dice Axel Fontaine (un arquitecto promotor de estos monolitos) es que tu podrías eventualmente usar colas para comunicar los módulos.

[@davidemanuelsans257]

Excelente! Otra alternativa al respecto: Porto SAP (github.com/Mahmoudz/Porto). También va en la misma línea: modularizar correctamente y en base a dominios una aplicación monolítica.

[@samueldavidgomezramos7880]

Qué relación tiene este enfoque con DDD?

[@ManuelZapata]

Podrías usar DDD en varias partes del monolito. El repositorio que puse en la descripción tiene buenos ejemplos de esto.

[@oscarmera3580]

Gracias Manuel, era algo que te había pedido hace un tiempo. Cuando estés en Cali tengo que invitarte un par de cervezas :D

[@ManuelZapata]

Si, recuerdo muy bien cuando me sugeriste el tema. Lo puse en mi backlog y finalmente vio la luz. Ojalá se dé el espacio para esas polas! 🍻

[@luismigueldiaz8992]

Muy interesante! Cuales crees que son los drawbacks o posibles desventajas de utilizar esta arquitectura? .. sera que si los desarrolladores no son disciplinados se puede volver un problema?

[@ManuelZapata]

Ese es el eterno reto con el monolito. Que como todo está ahí, si no tiene la disciplina, unos buenos code reviews y buenos modificadores de acceso en el código, es posible que se terminen tomando atajos. El otro posible problema que veo es que exista acoplamiento a nivel de los datos, y luego sea más difícil separar las bases de datos.

[@miguelmavo5971]

Hola Manuel, hay posibilidad de comprar tu curso de arquitectura desde Argentina? saludos

[@ManuelZapata]

Hola Miguel. Gracias por el interés. Claro que sí. Lo puedes comprar por Paypal.

[@jesuscampos7307]

No veo que sea una arquitectura nueva. Es una arquitectura DDD donde se separan verticalmente los bounded contexts. No deja de ser un monolito mejor organizado. No tienes en cuenta muchas de las ventajas aportadas por los microservicios como el despliegue y escalado independiente y el trabajo de distintos equipos especializados en distintas secciones y en distintos repositorios sin interferir, desarrollos de verdad independientes con frameworks y plataformas diversas adecuadas a las necesidades, etc. Eso si, estas ventajas sólo compensan en aplicaciones de cierta envergadura debido a la complejidad que añaden.

[@ManuelZapata]

Como muchas tendencias, no necesariamente es algo nuevo. Solo algo que le pusieron un nombre distinto o que no tenía. El punto es: hacer microservicios por las razones correctas.

[@edwinsantos201]

Hola Manuel, no me queda muy claro la diferencia entre este approach y el de tener servicios ( no microservicios ) ya que al tener servicios, se sigue el mismo concepto no?

[@ManuelZapata]

Depende mucho de como tengas organizados los servicios. Ahí puede radicar la diferencia.

[@josevicente632]

Manuel que paso con lad charlas Nullpointer de los viernes??

[@ManuelZapata]

Pasaron a ser quincenales. La próxima será el 20 de noviembre en mi canal.

[@martingonzalez4648]

Excelente Presentacion Manuel, gracias, pero lo que he visto son como microservicios pero con gran cantidad de funcionalidad..

[@ManuelZapata]

Sigue siendo un monolito, pero con una mayor facilidad para que algún día, si es necesario, se vuelva microservicios.

[@fernandopoveda9861]

Son mas complicados de mantener los microservicios cuando son muchos, si claro...soluciona el tema de ceder una responsabilidad por cada microservicios lo que los convierte en una unidad mucho mas diluible y asimilable. Pero para entornos de integración muy grandes, pueden generar una plataforma un poco abrumadora.

[@samueldavidgomezramos7880]

Qué pasa si un módulo se cae y quien consume la API obtiene un 503 ? No es mejor que los módulos se comuniquen a través de un Bus de mensajería como se hace en una arquitectura de microservicios? De tal forma que si un módulo, microservicio o consumidor se cae los mensajes permanecen el Bus hasta que esté nuevamente disponible.

[@ManuelZapata]

El problema es que sigue siendo un monolito. Si se cae el monolito, se caen todos los módulos.

[@angelbarrios7868]

Me gustó tu vídeo, excelente. En mi opinión en esta opción de arquitectura estamos sacando lo peor de los 2 mundos, monolitos y las dificultades y retos de microservicios sin poder sacarle el máximo de provecho aunque habría que revisar los requerimientos. En lo personal solo lo usaría para algo súper puntual y teniendo una muy buena razón.

Suscrito!!!

[@ManuelZapata]

Bienvenido!

[@gerardocouso708]

Excelente video !! Muy bien explicado el tema, aunque me surge una pregunta: ¿Que alcance tiene la variedad de capas de código? ¿Es posible programar capas a nivel de Linux Bash Scripting? Gracias de antemano ...

[@ManuelZapata]

Hola Gerardo. Me imagino que al final tendrás una capa donde llamarás scripts de Linux Bash si lo necesitas. El nivel (alto o bajo) se lo das tu y el lenguaje de programación que estés usando.

[@josesepulveda910]

Como deberia organizar la base de datos, si una o varias tablas son compartidas por varios modulos ?

[@ManuelZapata]

Lo ideal es definir qué modulo es el "dueño" de la tabla. Si al final te das cuenta que hay dos módulos que la necesitan muchísimo, posiblemente esos módulos deban unirse en uno solo.

[@MagnusAnand]

Se parece al concepto de apps de Django. Puede ser?

[@samueldavidgomezramos7880]

Si uno de los cambios en uno de los módulos puede pasar a producción pero un cambio en otro módulo no puede pasar, qué se hace en ese caso?

[@ManuelZapata]

Ya te tocaría manejarlo a nivel de source control (quizá con feature branches o algo así).

[@elbertjosesalasbrochero6318]

Se puede crear una aplicación completa que muestre solo el módulo del usuario respectivo solamente y crear un súper usuario administración que tenga acceso a toda la aplicación. completa

[@hacd10]

Hola Manuel, me cuesta entender la diferencia entre ambos estilos. Microservicios puede ser tan pequeño como tú lo definas. ¿No sería eso lo mismo qué monolitos modulares? 🤔

[@ManuelZapata]

El monolito modular sigue siendo eso: un monolito. Se despliega TODO junto.

[@elvargas1327]

No puedo inscribirme a los mini-cursos gratuitos :(

[@ManuelZapata]

Ya lo solucionamos, Ernesto. Intenta de nuevo por favor.

[@CeroCool212004]

Qué diferencia hay entre los webservices y los microservicios??? O son lo mismo???

[@ManuelZapata]

Microservicios es una manera en que puedes organizar tu backend. Un webservice sencillamente es como un API que puedes consultar para que te retorne algo o ejecute un proces. Saludos.

[@williamdavid508]

hay un tema que no queda del todo claro o tal ves este incorrecto, es la comunicación entre los módulos, si la comunicación se realiza utilizando las mismas Apis dentro de un mismo ensamblaje puede ocurre una redundancia cíclica, es decir: si el modulo "A" esta Diseñado en capas o sus derivados como clean arquitecture y su capa de aplicación o negocio apunta a un capa de API la cual, es la única entrada de ejecución del mismo sistema lo mas probable es que ocurra una redundancia cíclica en cada componente. otra opción seria que cada modulo tuviera su ensamblaje de APIS, ósea, capa modulo con su proyecto de APIS , pero, ya no seria un monolito por que tendría varias entradas de ejecución y para cada proyecto un despliegue... entonces lo mejor a mi juicio y teniendo en cuenta el repositorio que sugeriste es utilizar un "InMemoryEventBus" con una cuarta capa para la integración de eventos utilizando un patrón pub-sub. una librería que encontré para facilitar esto es JKANG. sin embargo, seria mejor aclarar tu video por que no creo que sea posible la comunicación de la manera como la explicas en el video. gracias y feliz día.