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

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."

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.

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!

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

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

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

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

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

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!

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

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

Excelente explicación.

No cabe duda que la especialización cada vez es mayor y que soluciones sencillas y robustas de antes terminan siendo complejas por el tema de la especialización y de querer adoptar cada vez mas herramientas y productos. Esto que comentas lo haciamos desde hace más de 10 años con los Servidores de Aplicaciones, Maven (modules de Maven), Oracle, J2EE y Adobe Flex o jQuery

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.

Excelente video gracias por compartir tus conocimientos Manuel.

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.

Esto es buenísimo!!!

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!

Que explicación tan excelente, muchas gracias

Muy interesante Manuel muchas gracias por explicarlo tan claramente.

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 👍🏼

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!!

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.

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

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

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

Excelente material, muchas gracias !!!

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.

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

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!

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

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

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

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

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

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

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

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.

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.

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)

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!!!

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

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!

Buen video Manuel, ilustrativo material, gracias.

Excelente video. Gracias por compartir !

Me gustó, nuevo sub

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

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 :/

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?

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

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?

Excelente vídeo Visto en 08/11/2020

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.

Muy buen video Manuel, saludos desde Chile.

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

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

exclente muchas gracias!

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?

Buen vídeo

Al escuchar esto describe lo que es angular.

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.

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

Gracias por los videos!

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.

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.

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.

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.

Excelente.

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).

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

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.

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

Hay muchos nuevos programadores que solo creen que hacer microservicios es hacer 1-1 con cada objeto de la bd y nunca hn hecho un proyecto o formado parte de un proyecto grande y no saben darle escalabilidad .

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

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

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

Genial tu contenido.

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?

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 ...

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?

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?

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

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

Interesante opción para cuando existe esa incertidumbre de escalabilidad

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

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

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.

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

Esto es como Liferay creo?

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?

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

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

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

Me estás hablando de una aplicación fragmentada por módulos , eso se ve me empresas grandes , donde cada dependencia maneja su aplicativo para trabajar. Cómo por ejemplo los almacenistas tienen la aplicación de inventario . Los de ventas tienen otra aplicación los de , módulo de estadísticas.

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

La arquitectura de microservicios no se ideo para organizar mejor un proyecto. Se pensó para aprovechar las virtudes de varios lenguajes de programación. Por ejemplo, tengo un sistema en .net y quiero trabajar con IA, puedo hago un microservicio en python.

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

Qué relación tiene este enfoque con DDD?

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

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?