Facturación presenta un comportamiento diferenciado dentro del sistema
El procesamiento de facturación concentra operaciones que pueden presentar picos de carga y requerimientos de procesamiento diferentes al resto del núcleo de negocio.
CASO DE ESTUDIO / 02
Sistemas Distribuidos. Arquitectura · Escalabilidad · Resiliencia.
Una empresa dedicada a la gestión y alquiler de vehículos para servicios de movilidad cuenta con una plataforma centralizada para administrar clientes, vehículos, contratos, facturación, mantenimiento e integraciones con servicios externos.
La plataforma comenzó como un sistema monolítico y fue creciendo junto con el negocio, incorporando nuevas funcionalidades y aumentando progresivamente el volumen de operaciones y usuarios.
DESCUBRIMIENTO
Problema descrito por el cliente.
El crecimiento de la plataforma comenzó a generar dificultades para mantener y evolucionar el sistema. Algunas funcionalidades requieren cada vez más recursos y presentan necesidades de escalabilidad diferentes, mientras que otras continúan teniendo una carga de trabajo relativamente estable. El equipo también observa que los cambios en determinadas áreas requieren modificaciones sobre otras partes del sistema, aumentando los tiempos de desarrollo, la coordinación necesaria para los despliegues y el riesgo de afectar funcionalidades que actualmente operan con normalidad.
ARQUITECTURA ACTUAL
Arquitectura actual del sistema
La plataforma está construida sobre una arquitectura centralizada. Un único backend desarrollado con Spring Boot concentra las operaciones de clientes, ventas, facturación, inventario e integraciones externas, utilizando una misma base de datos PostgreSQL para almacenar y consultar la información del sistema.
CLIENT
Frontend
Interfaz de usuarios
APPLICATION
Spring Boot
Clientes · Ventas · Facturación · Inventario · Integraciones Externas
DATABASE
PostgreSQL
Datos transaccionales y reporting
ANÁLISIS
Hallazgos de la investigación
El análisis de la estructura actual permitió identificar diferentes niveles de acoplamiento y necesidades de evolución dentro de la plataforma. Los principales hallazgos se concentran en la forma en que las funcionalidades comparten código, datos y ciclos de despliegue.
Diferentes dominios evolucionan a velocidades distintas
Facturación e inventario requieren cambios con mayor frecuencia que otras áreas del sistema, generando necesidades de evolución diferentes dentro de la misma aplicación.
Los despliegues tienen como unidad a toda la aplicación
Los cambios realizados sobre una funcionalidad requieren desplegar la aplicación completa, aumentando la coordinación necesaria y el riesgo de afectar otras áreas del sistema.
Algunas integraciones tienen necesidades diferentes al núcleo de negocio
Las integraciones externas dependen de sistemas y condiciones que no están bajo el control de la aplicación, por lo que presentan requisitos de comunicación y manejo de errores diferentes a las operaciones internas.
No existe una separación clara de responsabilidades a nivel arquitectónico
La lógica de diferentes dominios de negocio se encuentra concentrada en las mismas clases y componentes, dificultando identificar límites claros entre responsabilidades y aumentar su autonomía.
EXPLICACIÓN TÉCNICA
¿Como identificamos los problemas?
El análisis combinó la revisión del funcionamiento del sistema con el estudio de su estructura interna. A partir de los hallazgos se evaluó el nivel de acoplamiento entre funcionalidades, sus diferentes necesidades de evolución y las condiciones necesarias para que determinadas áreas puedan operar de forma más independiente.
Revisión del funcionamiento del sistema
Se revisó cómo se utilizan las principales funcionalidades y cómo se relacionan entre sí las operaciones de clientes, ventas, facturación, inventario e integraciones externas.
Análisis de la estructura del código
La revisión del código mostró que distintas funcionalidades de negocio comparten clases y componentes dentro de la misma aplicación Spring Boot. Esta estructura dificulta establecer límites claros entre dominios y aumenta el acoplamiento entre cambios que pertenecen a diferentes áreas del sistema.
Revisión de las integraciones externas
Se analizaron las dependencias con servicios externos y su impacto sobre el flujo de la aplicación. Estas integraciones introducen condiciones de comunicación, tiempos de respuesta y posibles fallos que requieren un tratamiento diferente al de las operaciones internas del negocio.
Identificación de la causa arquitectónica
Los problemas identificados no corresponden a un único componente, sino a una falta de límites claros entre responsabilidades. La combinación de código compartido, ciclos de evolución diferentes y dependencias externas dentro de la misma aplicación limita la capacidad de escalar, desplegar y evolucionar determinadas áreas de forma independiente.
ENTREGABLES
Una arquitectura distribuida basada en límites claros.
La propuesta mantiene el núcleo transaccional dentro de un componente central y separa aquellas capacidades que presentan necesidades diferentes de evolución, escalabilidad o integración. De esta forma, facturación e integraciones externas pueden evolucionar de manera independiente sin fragmentar innecesariamente el resto del sistema.
CLIENT
Frontend
Interfaz de usuarios
API
API Gateway
Entrada y distribución de solicitudes
CORE
Core
Clientes · Ventas · Inventario
BILLING
Facturación
Procesamiento de facturación
EXTERNAL INTEGRATION
Integration Service
Servicio de integraciones externas
DATABASE
PostgreSQL
Persistencia del sistema
La propuesta no busca dividir el sistema de forma indiscriminada. El objetivo es establecer límites donde exista una necesidad real de autonomía, permitiendo una evolución progresiva y manteniendo el núcleo del negocio estable durante la transición.
PROPUESTA
Roadmap de implementación
La evolución propuesta se plantea de forma incremental, comenzando por establecer límites claros dentro del sistema y priorizando posteriormente aquellas capacidades cuya separación aporte beneficios concretos de autonomía, escalabilidad o resiliencia, manteniendo la continuidad funcional durante la transición.
01
FASE 1
Modularización
Separar responsabilidades y dependencias dentro del monolito, estableciendo límites claros entre los distintos dominios de negocio.
02
FASE 2
Identificación de candidatos
Detectar componentes con necesidades diferenciadas de autonomía, escalabilidad, evolución o integración que justifiquen una extracción.
03
FASE 3
Extracción incremental
Extraer los componentes seleccionados de forma progresiva, incorporando mecanismos de comunicación, manejo de errores y observabilidad antes de avanzar con nuevas separaciones.
04
FASE 4
Consolidación y evaluación
Medir los resultados obtenidos y evaluar el comportamiento de los componentes extraídos. A partir de la evidencia, decidir qué capacidades continúan evolucionando de forma independiente y cuáles permanecen dentro del núcleo del sistema.