Monolito Modular

Resumen

Un monolito modular es una aplicación que se despliega como una sola unidad pero cuyo código está organizado en módulos con fronteras bien definidas. Cada módulo encapsula una capacidad de negocio, tiene su propia API interna y no accede directamente a los datos de otros módulos.

Es el punto intermedio entre el monolito desordenado —el "big ball of mud"— y los microservicios. Ofrece la simplicidad operativa del monolito —un solo deploy, una sola base de datos, sin latencia de red entre módulos— con la claridad estructural de los microservicios. Si el día de mañana un módulo necesita escalar independientemente, extraerlo a un microservicio es mucho más fácil porque las fronteras ya existen.

Alcance y supuestos

Este paquete cubre el monolito modular como estrategia de diseño, su diferencia con el big ball of mud y su rol como paso intermedio. Asume familiaridad con patrones arquitectónicos.

Modelo mental

Un edificio de oficinas con paredes internas bien puestas. Es un solo edificio, pero cada piso tiene su especialidad —marketing, ingeniería, finanzas— y las puertas entre pisos están donde corresponde. Mudar un piso entero a otro edificio es posible porque la estructura interna ya está definida.

Uso práctico

• ✅ Proyectos que necesitan orden interno pero no justifican la complejidad operativa de microservicios.
• ❌ Equipos que ya escalan a 50+ personas con necesidades de deploy independiente real.

Ejemplo trabajado: estructurar un monolito Spring Boot

Un equipo organiza su monolito Spring Boot en 4 módulos: orders, payments, catalog, notifications. Cada módulo tiene sus propios servicios, repositorios y DTOs. El acceso entre módulos es solo mediante interfaces, nunca directo a tablas. Cuando catalog necesita escalar independientemente un año después, separarlo a un microservicio toma 2 semanas en vez de 3 meses.

Evidencia

• El monolito modular es la arquitectura recomendada por Simon Brown (C4 model) y Kamil Grzybek como paso intermedio antes de considerar microservicios.