Backend, dominio y testing.
Las tres piezas que sostienen sistemas que no pueden fallar.

Los sistemas no fallan de golpe. Se van endureciendo, hasta que un cambio de una línea necesita tres equipos, dos reuniones y un permiso.

Diez años desarmando eso donde no se puede fallar: retail aéreo, órdenes, facturación fiscal.

Diagrama isométrico de tres capas — backend, modelado de dominio y testing — conectadas entre sí.
  • DDD
  • SOLID
  • Arquitectura
  • Buenas Prácticas
  • C#
  • .NET
  • ASP.NET Core
  • EF Core
  • Vue
  • Nuxt
  • React
  • Angular
  • TypeScript
  • REST APIs
  • SQL Server
  • PostgreSQL
  • Azure Service Bus
  • Git
  • Docker
  • Azure
  • CI/CD
  • Testing

Experiencia en dominios complejos

Sistemas de aerolíneas, sin el legacy de por medio

Cuatro años sobre el mismo problema en distintas plataformas: la aerolínea vende, pero su sistema de reservas no sabe qué es una orden. El trabajo fue separar el modelo de venta del legacy que lo tenía secuestrado, y hacerlo sin apagar la venta un solo día.

  • Modelo de reservas rediseñado desde el flujo legacy al de Offer & Order
  • Legacy contenido detrás de un anti-corruption layer, no propagado
  • Integraciones con PSS y pasarelas de pago
  • Cobertura sostenida sobre 85 % con quality gates bloqueantes
  • AI-Driven Development (SDD, Skills, MCP, Harness)

Maqueta ilustrativa de una compra de vuelos completa: se elige un destino, se agregan dos vuelos al itinerario, se selecciona un asiento en el mapa de cabina y se confirma el pago. Abajo corre el ciclo de vida de la orden — creada, asiento asignado, pago autorizado y emitida.

Recaudación de impuestos en distintos paises

Facturación electrónica en cuatro países, cada uno con su organismo, su formato y sus propios reglas. La tentación era escribir cuatro sistemas. La respuesta fue un núcleo de emisión común y un adaptador por fisco, con el rechazo tratado como estado del dominio y no como excepción.

  • Un solo ciclo de vida del comprobante para los cuatro organismos
  • Reglas de cada fisco aisladas detrás de un puerto, no esparcidas por toda la aplicación
  • Reenvío idempotente: un comprobante nunca se emite dos veces
  • Volumen diario de clientes corporativos, bajo cumplimiento normativo

Maqueta ilustrativa de un tablero de operaciones de facturación electrónica en cuatro países. Muestra una cola de emisión con comprobantes de Argentina, Colombia, Bolivia y Costa Rica avanzando por los estados recibido, validado, firmado, enviado al fisco y autorizado, incluido un rechazo del organismo que se reintenta y termina autorizado.

Que la IA entienda el proyecto, no solo el archivo

Hoy la mayor parte de mi trabajo no es escribir código: es construir las herramientas que lo escriben. Agentes con una sola responsabilidad cada uno —planificar, implementar, testear, revisar el PR—, servidores MCP que les dan navegación real del codebase. La decisión de diseño sigue siendo mía; sostenerla dejó de ser manual.

  • Un agente por etapa: plan, implementación, tests y revisión de PR
  • Servidores MCP propios: el agente navega por símbolos, no por texto
  • Quality gates que bloquean antes de que el diff llegue al review humano
  • Prácticas y tooling transferidos al equipo en sesiones internas

Maqueta ilustrativa del flujo de trabajo con agentes: una misma tarea se reparte desde el orquestador a tres agentes de Claude Code, cada uno en su propio worktree de git. Los tres recorren las mismas cuatro fases —planificar, implementar, correr los tests y revisar— y después se comparan por diff, tests y cobertura. Gana el candidato B; el C queda afuera por no llegar al umbral de cobertura. El pull request resultante pasa los cuatro checks y se mergea.

La arquitectura es la decisión de qué no acoplar.

La mayor parte del trabajo es decir que no a tiempo, justo donde el costo de decir que sí recién aparece dos años después.

El dominio primero

Modelar el negocio, no la base de datos

Límites explícitos y el legacy contenido detrás de un adaptador. Hexagonal donde justifica su costo, y un endpoint CRUD donde esa es la respuesta honesta.

Tests como diseño

Si cuesta testear, el diseño está mal

Suites orientadas a comportamiento que sobreviven a los refactors. La cobertura alta es la consecuencia de un buen límite, nunca el objetivo en sí.

Traspaso

El equipo se lo queda cuando me voy

Decisiones documentadas, revisión de pull requests y pairing. Escribo para quien se sume dentro de dieciocho meses, no para quien ya tiene el contexto.

Otros trabajos

2015 — 2026
  • xxxxClientes propiosSistemas y herramientas a medidaFreelance
  • 2025Travel · Retail aéreoMigración al modelo Offer & OrderFull-time
  • 2022Travel · PSS de aerolíneasReservas, check-in y pagosFull-time
  • 2017Factura ElectrónicaEmisión electrónica de comprobantesFull-time
  • 2015Banca · Core bancarioAuditoría de procesos y sistemasFull-time

Trabajo con pocos proyectos a la vez

No hace falta que lo tengas claro.
Para eso está la primera charla.

Contame qué te está frenando: con contexto, con lo que ya intentaste, con lo que está en juego. Si encaja, arrancamos. Si no soy yo, te digo quién sí.

Escribime