Por qué Businext utiliza un monolito modular

La discusión real no es monolito vs microservicios

En arquitectura de software empresarial, la conversación entre monolitos y microservicios suele presentarse como una evolución natural del sistema. Primero se empieza con un monolito y después se “escala” hacia microservicios.

En la práctica, esa narrativa es demasiado simplificada.

La decisión correcta depende de tres factores mucho más concretos:

• qué tan claros son los límites de dominio
• cuánto costaría coordinar transacciones entre servicios
• qué complejidad operativa puede sostener el equipo

Para plataformas ERP estas preguntas son especialmente importantes porque múltiples dominios comparten una verdad operativa común.

La naturaleza de los sistemas ERP

Un ERP combina varios dominios del negocio:

finanzas
inventario
ventas
conciliaciones
reporteo
operación administrativa

Estos dominios son distintos, pero rara vez son independientes.

Un cambio en ventas puede afectar inventario.
Un movimiento de inventario puede tener impacto contable.
Una conciliación financiera puede depender de eventos generados por otros módulos.

Esto significa que muchos flujos del sistema requieren transacciones coordinadas y auditabilidad confiable.

Separar estos flujos demasiado pronto puede convertir una arquitectura limpia en papel en una plataforma más difícil de operar.

Por qué muchos equipos se mueven demasiado pronto

Los microservicios prometen varios beneficios reales:

• independencia de despliegue
• propiedad clara por equipo
• escalabilidad aislada
• desacoplamiento entre dominios

El problema aparece cuando esos servicios se extraen antes de que los límites del dominio estén realmente definidos.

Esto suele producir varios síntomas conocidos:

• servicios que aún necesitan conocimiento interno unos de otros
• transacciones distribuidas frágiles
• aumento del costo de observabilidad y monitoreo
• más tiempo administrando infraestructura que mejorando el dominio

Para sistemas empresariales en crecimiento, esto suele ser demasiada complejidad demasiado pronto.

El monolito modular como arquitectura deliberada

En Businext la decisión fue construir la plataforma como un monolito modular.

Esto significa que todos los dominios viven dentro del mismo backend, pero cada uno mantiene límites claros de ingeniería.

Cada área del negocio funciona como un módulo independiente:

CRM
HRM
SRM
PMS
EMS
RMS
IMS
SMS
AMS
EIS

Cada módulo se implementa como una aplicación FastAPI montada dentro del mismo proceso del backend.

Este enfoque permite:

• integración directa entre dominios
• consistencia transaccional simple
• despliegue en un único servicio
• menor complejidad operativa

Para un equipo pequeño — incluso un solo desarrollador — estas propiedades son críticas.

Qué problema evita este enfoque

El monolito modular evita uno de los problemas más comunes en sistemas distribuidos prematuros: mover el acoplamiento del código hacia la red.

Cuando un sistema aún depende de decisiones coordinadas entre dominios, separar servicios no elimina el acoplamiento. Solo lo transforma en:

• llamadas entre APIs
• eventos distribuidos
• colas de mensajes
• transacciones eventualmente consistentes

Esto aumenta la complejidad operativa sin necesariamente mejorar el modelo del dominio.

Cuándo los microservicios empiezan a tener sentido

Los microservicios se vuelven una opción más atractiva cuando varias condiciones ya están presentes:

• dominios con independencia demostrada
• equipos que pueden operar servicios completos
• necesidades de escalado diferentes entre módulos
• madurez operativa en observabilidad y manejo de fallas

En ese punto, separar servicios puede reducir riesgo en lugar de aumentarlo.

Tres preguntas útiles antes de distribuir un sistema

Antes de separar un servicio, tres preguntas suelen ser más útiles que cualquier checklist genérico:

1. ¿Este dominio puede evolucionar sin reinterpretar reglas internas de otro dominio?
2. ¿El equipo puede operar fallas distribuidas con confianza?
3. ¿Extraer este servicio reduce acoplamiento o solo lo mueve a APIs?

Si el acoplamiento sigue existiendo y solo cambia de lugar, el servicio probablemente todavía no está listo para existir por separado.

Una restricción especial del software empresarial

Los sistemas ERP y financieros tienen una restricción importante: verdad compartida.

Muchos flujos requieren consistencia coordinada:

• aprobaciones cruzan varios conceptos del sistema
• cierres financieros dependen de estados coherentes
• conciliaciones necesitan datos confiables entre dominios
• soporte necesita explicar eventos completos del sistema

Estas propiedades hacen que la distribución prematura sea particularmente costosa.

Una postura pragmática

En lugar de preguntar “¿cuándo debemos usar microservicios?”, una pregunta más útil es:

¿Qué límites de dominio son lo suficientemente fuertes como para que distribuir el sistema realmente reduzca riesgo?

Para muchas plataformas empresariales internas, el camino más práctico es:

• comenzar con un monolito modular
• definir límites claros de dominio desde el inicio
• observar dónde aparecen fricciones reales
• extraer servicios solo cuando esos límites estén probados

Este enfoque mantiene la arquitectura alineada con la realidad del negocio y no con tendencias arquitectónicas.

Businext no fue diseñado como microservicios, sino como un monolito modular donde cada dominio del negocio evoluciona dentro de una aplicación FastAPI montada en el mismo backend.