/ A. Pozo

Disponible · Aceptando proyectos seleccionados para 2026

Senior Full-Stack Developer para sistemas empresariales complejos

Diseño backends orientados al dominio — Hexagonal, DDD, CQRS — para ERP, contabilidad, nómina y flujos operativos. La misma disciplina de kernel propio en Java/Spring y TypeScript/NestJS.

  • ERP
  • Accounting Systems
  • Backend Architecture
  • DDD
  • Hexagonal Architecture
  • Clean Architecture
  • TDD
Enfoque
ERP · Contabilidad · Operaciones
Stack
TypeScript · Node · Postgres
Aproximación
DDD · Hex · TDD
Ubicación
La Habana, Cuba

Qué hago

Cimientos backend para sistemas en los que la corrección no es negociable.

Trabajo seleccionado

Casos de estudio

Todo el trabajo →

Aproximación

Una aproximación disciplinada a construir software del que una organización pueda depender durante años.

  1. 01

    El dominio en el núcleo

    Lógica de dominio pura — sin frameworks, sin infraestructura. Las reglas contables, las invariantes de inventario y los flujos de pedido viven intactos respecto a transporte o persistencia.

  2. 02

    Puertos y adaptadores

    Los casos de uso entrantes mueven el dominio a través de puertos explícitos; las integraciones salientes (BD, colas, terceros) implementan adaptadores. Intercambiables, testeables, observables.

  3. 03

    Los tests como presión de diseño

    TDD como herramienta de feedback: rojo, verde, refactor. Tests unitarios para el dominio, de integración en las fronteras, de contrato con sistemas externos — la pirámide se mantiene en forma.

  4. 04

    Decisiones documentadas

    ADRs para los trade-offs, lenguaje ubicuo para significado compartido, runbooks para lo que despierta a alguien a las 3am. El sistema se explica solo.

Domain Application Infrastructure HTTP · CLI · Jobs DB · Queue · APIs

Arquitectura hexagonal · flujo de información

En el horizonte

Lenguaje natural como interfaz de primer nivel a los sistemas empresariales.

Un módulo de asistente IA actualmente en endurecimiento de producción sobre el backend ERP. Las peticiones en lenguaje natural se clasifican en intents y se enrutan de forma determinista a un registro de Tools de solo lectura que envuelven los servicios de aplicación existentes. La autorización vive dentro del contexto de access — sin modelo de permisos paralelo. La siguiente fase incorpora tools de escritura con confirmación HITL y estado conversacional para gestión operacional de ventas end-to-end.

intent classifier · router Sale . getSaleById Sale . searchSales Sale . getTopSellingProducts Sale . createDraft Sale . removeDraft Inventory . getStockAvailability Catalog . getProductDefinition Catalog . searchProducts 9 tools · 12 intents · 3 LLM providers
  1. 01

    Routing determinista de tools

    Las intents se resuelven con un clasificador por keywords, no con el LLM. El LLM compone la respuesta, nunca decide qué llamar. Los modos de fallo degradan a un fallback determinista.

  2. 02

    Proveedores LLM intercambiables

    Un único puerto de proveedor — tres implementaciones: mock para tests, Ollama para inferencia local privacy-first, compatible con OpenAI para despliegue gestionado. Se cambia por configuración; el dominio no se entera.

  3. 03

    La autorización vive donde le toca

    Cada llamada a una tool pasa por el AuthorizeActionHandler existente. Tenant, business unit y permisos siguen siendo propiedad del contexto de access. El asistente nunca los esquiva.

Tools registradas
9
Intents clasificadas
12
Proveedores LLM
3
Flujo de confirmación
HITL

Actualmente

Diseñar la próxima generación de sistemas empresariales requiere manos cuidadosas.

Si estás reconstruyendo una parte crítica de tu operación — contabilidad, ERP, flujos financieros — y necesitas un par de manos senior en la arquitectura, me gustaría escucharlo.