Definir límites de dominio en un ERP antes de que los módulos escalen

Cuando un ERP empieza a volverse difícil de cambiar

Un ERP no se vuelve difícil de mantener cuando crece en líneas de código.
Se vuelve difícil cuando los módulos empiezan a depender de reglas que en realidad pertenecen a otra área del negocio.

Ese era el riesgo al diseñar Businext ERP.

En un sistema empresarial real, las áreas no viven aisladas. Finanzas necesita entender movimientos de inventario para validar ciertos eventos. Ventas necesita conocer el estado financiero del cliente. Recursos humanos controla accesos que afectan a toda la plataforma.

Ese tipo de interacción es normal.

El problema aparece cuando esas dependencias se resuelven de forma implícita: joins directos entre tablas de distintos módulos, lógica duplicada en múltiples endpoints o consultas que reinterpretan reglas que deberían tener un dueño claro.

En ese punto el sistema sigue funcionando, pero empieza a perder algo más importante que rendimiento: claridad.

El problema de escala en un ERP no es solo técnico

Cuando un ERP crece, cada área del negocio amplía su responsabilidad.

Finanzas no solo gestiona saldos o movimientos. También define cierres de periodo, conciliaciones y semántica contable.
Inventario no solo rastrea stock. Controla movimientos operativos que después impactan reportes y análisis.
Ventas no solo registra pedidos. Define compromisos comerciales, precios y relaciones con clientes.

Si esas responsabilidades no tienen límites claros, el sistema empieza a compensar con conveniencia técnica.

Un módulo lee directamente tablas de otro porque es más rápido que diseñar una interfaz.
Se duplican reglas de negocio en diferentes endpoints o pantallas.
Se agregan condicionales dispersos porque nadie tiene certeza de dónde vive realmente una regla.

El resultado es un sistema que funciona, pero cada cambio introduce incertidumbre.

La decisión de arquitectura en Businext

Desde el inicio de Businext ERP la arquitectura se pensó en términos de dominios del negocio.

Cada área opera como un módulo independiente dentro de la plataforma:

• Businext CRM — clientes, carteras y análisis comercial
• Businext HRM — recursos humanos
• Businext SRM — proveedores
• Businext PMS — compras
• Businext EMS — control de gastos
• Businext RMS — ingresos
• Businext IMS — inventarios y productos
• Businext SMS — ventas, precios y descuentos
• Businext AMS — contabilidad
• Businext EIS — facturación electrónica

En la implementación técnica esto se refleja en aplicaciones FastAPI montadas dentro del mismo backend.

Cada módulo expone su propio conjunto de rutas y servicios.

Cada dominio mantiene su propia estructura interna de ingeniería:

• modelos SQLAlchemy
• schemas Pydantic
• routers de API
• services donde vive la lógica de negocio

Esto permite que la evolución de cada área ocurra dentro de límites claros, incluso cuando comparten una misma base de datos productiva.

Por qué los límites de dominio son arquitectura

Separar dominios no se trata solo de organizar carpetas.

Se trata de decidir quién posee cada concepto del negocio.

Por ejemplo:

Finanzas posee las reglas contables y la integridad de periodos.
Ventas puede consultar información financiera, pero no redefine qué significa un estado contable válido.
Inventario define la validez de los movimientos de stock, pero no debería incluir lógica contable solo porque una operación tenga impacto financiero posterior.

Cuando estas decisiones no están claras, el sistema se llena de reglas implícitas que aparecen en consultas, endpoints o scripts operativos.

Ese es el tipo de acoplamiento que hace que un ERP se vuelva frágil.

Por qué el acceso directo a tablas suele iniciar el problema

En muchos sistemas internos, leer tablas de otro módulo parece una optimización inocente.

Un desarrollador necesita un campo extra.
Hace un join directo.
Otro endpoint copia esa consulta.
Luego una excepción de negocio se resuelve en una pantalla pero no en la API.

Lo que parecía eficiencia termina convirtiéndose en política distribuida.

Esto es especialmente peligroso en software ERP porque muchas reglas no son evidentes desde el esquema de la base de datos.

Qué periodos aún pueden editarse.
Cuándo un movimiento de inventario sigue siendo provisional.
Cuándo una acción comercial se vuelve compromiso financiero.
Cómo interactúan permisos con contexto operativo.

Esas son reglas de dominio, no detalles de persistencia.

Un modelo práctico para definir límites

En Businext, una forma útil de mantener los límites claros fue hacer cuatro preguntas para cada concepto relevante del negocio:

• Qué área posee la regla
• Qué otras áreas consumen el resultado
• Cuál es el contrato entre ellas
• Qué ocurre si un consumidor intenta saltarse ese contrato

Este enfoque vuelve las decisiones más explícitas.

Si finanzas posee el cierre contable, otros módulos deben consumir el resultado de ese cierre, no reinterpretarlo desde tablas internas.

Si inventario valida movimientos, otros servicios pueden reaccionar a esos eventos, pero no deducir reglas desde el estado de la base de datos.

El tradeoff: más coordinación explícita

Definir límites de dominio no reduce la complejidad del negocio.
Lo que hace es volverla visible.

Algunos flujos requieren coordinación entre módulos.
A veces hay que diseñar contratos o servicios intermedios en lugar de leer directamente tablas.

Eso puede parecer más trabajo en el corto plazo.

Pero en sistemas empresariales reales ese esfuerzo evita una deuda mucho más costosa: el acoplamiento oculto entre módulos.

Efecto operativo

El beneficio principal no fue estético.

Fue poder hacer cambios con mayor seguridad.

Los cambios en finanzas se volvieron más aislables.
La lógica de inventario mantuvo coherencia operativa.
Las nuevas funcionalidades tuvieron que declarar explícitamente sus dependencias.

Eso es lo que realmente mantiene mantenible a un ERP.

No la ausencia de complejidad, sino la presencia de propiedad clara sobre las reglas del negocio.

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.

Esto es especialmente cierto cuando:

• el ERP todavía sigue creciendo en módulos;
• varias personas tocan la misma plataforma con el tiempo;
• contabilidad y operación deben mantenerse consistentes.

Efecto operativo

El beneficio más fuerte no fue estético. Fue seguridad para decidir. Los cambios en finanzas se volvieron más aislables. El comportamiento de inventario se mantuvo coherente. Las nuevas funcionalidades tuvieron que declarar sus dependencias en lugar de inventarlas silenciosamente.

Eso es lo que mantiene mantenible a un ERP. No la ausencia de complejidad, sino la presencia de propiedad explícita.

Si estás diseñando o refactorizando una plataforma similar, un siguiente paso útil es combinar este trabajo con servicios FastAPI orientados a transacciones de negocio y con una visión más amplia sobre arquitectura de plataformas ERP.