Arquitectura de plataformas ERP para operación real

El problema real de la arquitectura ERP

Las discusiones sobre arquitectura ERP suelen empezar con tecnologías. Frameworks, bases de datos o estilos de despliegue. En la práctica, el problema central es cómo permitir que múltiples dominios del negocio convivan dentro de una misma plataforma sin que cada módulo termine absorbiendo reglas que no le pertenecen.

En un sistema empresarial real cada área empuja la arquitectura en direcciones distintas.

Finanzas necesita trazabilidad y cierres confiables.
Inventario necesita reglas estrictas de movimiento.
Ventas necesita velocidad y visibilidad del estado del cliente.
Recursos humanos necesita controlar permisos y estructura organizacional.

El ERP debe soportar todo eso y seguir siendo comprensible cuando el sistema crece.

Por eso la arquitectura ERP trata principalmente de límites, contratos y propiedad de dominio.

Empezar desde el modelo operativo

Antes de elegir servicios o despliegue, la plataforma debe responder una pregunta más fundamental:

¿Qué flujos operativos mantienen funcionando a la empresa?

En la mayoría de los ERP estos flujos incluyen:

• registrar operaciones financieras correctamente
• coordinar ventas con cumplimiento operativo
• rastrear movimientos de inventario con auditabilidad
• soportar procesos administrativos y de recursos humanos
• producir reportes coherentes entre áreas

Cuando la arquitectura empieza desde tablas en lugar de flujos operativos, el resultado suele ser un backend fácil de generar pero difícil de evolucionar.

Descomposición por dominios del negocio

En Businext la descomposición principal del sistema se hizo por dominios del negocio.

Cada área se modela como un módulo con responsabilidades claras:

• CRM — clientes y cartera
• HRM — recursos humanos
• SRM — proveedores
• PMS — compras
• EMS — gastos
• RMS — ingresos
• IMS — inventarios y productos
• SMS — ventas, precios y descuentos
• AMS — contabilidad
• EIS — facturación electrónica

Cada módulo funciona como una aplicación FastAPI montada dentro del mismo backend.

Cada dominio mantiene su propia estructura de ingeniería:

• modelos SQLAlchemy
• schemas Pydantic
• routers de API
• services con lógica de negocio

Este enfoque permite que cada dominio evolucione sin que los cambios se propaguen accidentalmente por toda la plataforma.

Arquitectura pensada para evolución

Muchos sistemas internos funcionan bien durante su primer año incluso con límites débiles. Los problemas aparecen cuando:

• crecen las funcionalidades
• aumentan excepciones operativas
• más personas trabajan en el código
• la operación depende cada vez más del sistema

En ese momento la calidad de la arquitectura se mide por qué tan seguro es cambiar el sistema.

Una arquitectura ERP útil enfatiza:

• propiedad explícita por dominio
• capas de servicio que modelan flujos de negocio
• consistencia de datos antes que conveniencia de implementación
• visibilidad sobre transiciones operativas críticas

Por qué el monolito modular fue la decisión correcta

Para muchas plataformas ERP adoptar microservicios demasiado pronto agrega complejidad antes de que el modelo del sistema esté claro.

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

Esto permitió mantener:

• un límite de despliegue simple
• integración directa entre dominios
• contratos internos explícitos
• menor complejidad operativa para un solo desarrollador
• evolución rápida del sistema mientras el modelo maduraba

Un monolito modular funciona solo cuando los límites de dominio son reales. Un monolito sin límites claros simplemente centraliza el acoplamiento.

Dónde paga una buena arquitectura

Una arquitectura ERP sólida produce beneficios en tres áreas clave.

Aislamiento de cambios

Cuando cambian reglas financieras, otros módulos no deberían reinterpretarlas por su cuenta. Deben consumir una capacidad del dominio que posee esa regla.

Soporte operativo

El sistema debe permitir entender qué pasó, por qué pasó y qué transición de estado llevó a ese resultado.

Confianza en los datos

Los reportes deben reflejar la verdad poseída por cada dominio.

Una regla práctica

Una regla útil para diseñar ERP es simple:

Todo flujo importante para la operación debe tener un dominio que posea la decisión y una ruta visible para ejecutarla.

Si esa propiedad no está clara, el flujo probablemente depende de acoplamiento accidental.

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.