La deuda técnica no es un problema de código viejo
En la mayoría de los sistemas que llegamos a rescatar en BROTE, el problema no es la antigüedad del código. Es el acoplamiento. Capas de lógica de negocio mezcladas con consultas SQL. Funciones que hacen tres cosas distintas. Módulos que dependen directamente de la base de datos, del proveedor de email y del sistema de pagos al mismo tiempo.
Cuando todo está acoplado a todo, cambiar cualquier cosa es una apuesta. Y las empresas en crecimiento no pueden apostar: necesitan iterar, agregar funcionalidades y corregir bugs sin frenar las operaciones.
Qué es la arquitectura hexagonal
La arquitectura hexagonal —también llamada puertos y adaptadores, propuesta por Alistair Cockburn— parte de una idea simple: el núcleo de tu aplicación (la lógica de negocio) no debería saber nada sobre cómo se accede a ella ni cómo accede al mundo exterior.
En lugar de que tu lógica llame directamente a PostgreSQL, a Mercado Pago o a SendGrid, define puertos: interfaces abstractas que describen qué necesita sin especificarcómo. Los adaptadores son las implementaciones concretas que conectan esos puertos al mundo real.
Visualmente, el sistema tiene tres capas:
- Dominio: la lógica de negocio pura. Sin imports de frameworks, sin imports de bases de datos.
- Aplicación: los casos de uso que orquestan el dominio. Sabe qué hacer, no cómo hacerlo.
- Infraestructura: todo lo externo. Base de datos, APIs de terceros, email, sistema de archivos.
Cómo esto resuelve la deuda técnica
La deuda técnica se acumula principalmente de tres formas, y la arquitectura hexagonal ataca las tres:
1. Acoplamiento a la base de datos
En sistemas sin arquitectura definida, la base de datos permea todo. Cambiar de PostgreSQL a MongoDB —o simplemente renombrar una columna— implica tocar decenas de archivos. Con hexagonal, la base de datos es un adaptador. El dominio define un puerto UserRepository con los métodos que necesita; la implementación concreta vive sola en infraestructura.
2. Lógica de negocio difícil de testear
Si tu lógica de negocio está entrelazada con llamadas a la base de datos, testearla requiere levantar toda la infraestructura. Resultado: los equipos dejan de escribir tests porque son lentos y frágiles. Con hexagonal, el dominio se testea con tests unitarios puros, sin mocks complejos ni bases de datos en memoria.
3. Imposibilidad de cambiar proveedores
Un cliente llegó a nosotros porque su sistema de pagos —integrado directamente en 40 archivos distintos— era Stripe, y necesitaba agregar Mercado Pago para el mercado argentino. Con una arquitectura hexagonal, ese cambio es agregar un nuevo adaptador. El resto del sistema no se toca.
Un ejemplo concreto: antes y después
En un sistema típico sin arquitectura, un caso de uso de "crear pedido" suele verse así:
// ❌ Sin arquitectura: todo acoplado
async function crearPedido(datos) {
const cliente = await db.query(
'SELECT * FROM clientes WHERE id = $1',
[datos.clienteId]
);
const total = datos.items.reduce((acc, item) => acc + item.precio, 0);
await db.query(
'INSERT INTO pedidos (cliente_id, total, estado) VALUES ($1, $2, $3)',
[datos.clienteId, total, 'pendiente']
);
await fetch('https://api.stripe.com/v1/payment_intents', {
method: 'POST',
body: JSON.stringify({ amount: total * 100, currency: 'usd' })
});
await nodemailer.sendMail({
to: cliente.email,
subject: 'Tu pedido fue recibido'
});
}Con arquitectura hexagonal:
// ✅ Con hexagonal: dominio aislado
class CrearPedidoUseCase {
constructor(
private pedidos: PedidoRepository,
private pagos: PagoGateway,
private notificaciones: NotificacionService
) {}
async ejecutar(comando: CrearPedidoComando): Promise<Pedido> {
const pedido = Pedido.crear(comando.clienteId, comando.items);
await this.pedidos.guardar(pedido);
await this.pagos.cobrar(pedido.total, pedido.id);
await this.notificaciones.confirmar(pedido);
return pedido;
}
}El caso de uso no sabe si el repositorio usa PostgreSQL o MongoDB. No sabe si el gateway de pagos es Stripe o Mercado Pago. No sabe si las notificaciones van por email o WhatsApp. Eso es lo que hace posible cambiar cualquiera de esas piezas sin tocar la lógica de negocio.
¿Cuándo vale la pena aplicarla?
La arquitectura hexagonal no es gratis. Tiene una inversión inicial en estructura que en sistemas muy pequeños o MVPs puede no justificarse. Nuestra regla práctica:
- MVP o prototipo de validación: no la apliques todavía. Iterá rápido, aceptá la deuda consciente.
- Sistema que va a producción y va a crecer: aplicala desde el inicio. El costo de no hacerlo se paga en los primeros 6 meses.
- Sistema legacy existente: introducila incrementalmente, empezando por los módulos más críticos y más cambiantes.
Lo que vemos en la práctica en Argentina y Latinoamérica
En el ecosistema de software argentino y latinoamericano, la mayoría de los sistemas que llegan a rescate comparten el mismo patrón: empezaron como un MVP urgente, funcionaron, crecieron, y nadie frenó a refactorizar. La presión operativa siempre ganó.
El resultado es software que el equipo original puede mantener con dificultad, pero que nadie más puede tocar. Cuando esa persona se va —o cuando el negocio crece más rápido que la capacidad del equipo de hacer cambios— el sistema se convierte en un freno.
La arquitectura hexagonal no es una solución mágica, pero sí es una de las herramientas más efectivas para construir software escalable que un equipo pueda mantener a lo largo del tiempo.
¿Tu sistema tiene deuda técnica acumulada?
En BROTE ofrecemos un diagnóstico técnico gratuito: revisamos tu sistema, identificamos los puntos críticos de acoplamiento y te entregamos un plan de modernización incremental que no detiene tus operaciones.