A quién estarías financiando
Diseño la parte del sistema que tiene que estar bien.
Soy Alejandro Pozo — arquitecto backend senior para software empresarial complejo. Núcleos de ERP, cierres de nómina, movimientos contables: los motores donde una respuesta equivocada no es un bug, es un pasivo.
El trabajo
No funcionalidades. Cimientos.
Cualquiera puede añadir una pantalla. Yo construyo la capa que va debajo — el modelo de dominio, las fronteras, el kernel — para que la décima funcionalidad cueste menos que la primera y el sistema siga siendo editable años después de su lanzamiento. Esa es la línea entre el software que se compone y el que se degrada.
Cómo trabajo
Cada proyecto recorre el mismo camino disciplinado.
Selecciona cada fase. Nada se improvisa — la secuencia se sostiene tanto si el stack es Java como TypeScript.
Empezar por el lenguaje
Los bounded contexts emergen de cómo el equipo de operaciones piensa realmente el trabajo — no de un esquema de base de datos. Vocabulario compartido antes de una línea de código.
Trazar las fronteras
Costuras explícitas entre contextos. Cada uno es dueño de su modelo; la integración es deliberada. Aquí es donde la mayoría de los sistemas se ganan o se pierden en silencio.
Construir el kernel
Buses, puertos, value objects, saga, outbox, idempotencia — una base hecha a mano. Pagas el coste inicial una vez; cada contexto posterior cuesta menos.
Coexistir, nunca reescribir a ciegas
Los contextos nuevos llegan a capas limpias mientras el legacy sigue funcionando. Capas anti-corrupción puentean ambos lados. Un god-service se retira solo cuando su reemplazo se lo ha ganado bajo carga real.
El activo que se compone
Cada bounded context cuesta menos que el anterior.
El kernel se construye una vez. Después, cada contexto nuevo lo reutiliza — así el costo marginal de crecer baja en vez de subir. Añade contextos y observa cómo se separan las dos curvas de costo.
La mayoría de los sistemas se vuelven más caros de extender cada año. Un kernel hace que se vuelvan más baratos. Esa brecha es lo que estás financiando.
Principios
Cuatro reglas que no negocio.
- 01
Construir el kernel primero
Cada patrón reutilizable vive en una base hecha a mano. Cada contexto nuevo cuesta menos porque la base ya pagó el coste inicial.
- 02
Patrones por encima de frameworks
La arquitectura viaja. Hexagonal, DDD y CQRS funcionan igual en Java/Spring que en TypeScript/NestJS. El framework es solo un vehículo de entrega.
- 03
Coexistencia sobre reescrituras
El legacy sigue en producción mientras los contextos nuevos demuestran su valor. Capas anti-corrupción puentean ambos lados. Nada se retira por fe.
- 04
La documentación va con el código
Cada decisión no evidente tiene un markdown al lado — bounded contexts, narrativas de refactor, runbooks. El sistema se explica solo.
Dos stacks, una arquitectura
El framework es el vehículo. La disciplina es el activo.
Trabajo en dos stacks paralelos. Los patrones son idénticos en ambos. Cambia el stack abajo — solo cambian los adaptadores; el dominio del núcleo nunca se mueve.
Por esto financiar juicio supera a financiar a un especialista en frameworks. El juicio viaja entre stacks; el conocimiento de framework caduca con ellos.
Trayectoria
De dónde viene la disciplina.
Ingeniero de Software, graduado por la Universidad de Oriente en Santiago de Cuba. Proyectos recientes: un backend ERP con una arquitectura de quince contextos y un kernel propio de primitivos CQRS, saga y outbox; y una plataforma full-stack de RR.HH. y nómina con un kernel paralelo en TypeScript. Los mismos patrones, probados dos veces, en dos lenguajes.
Stack
- Languages
- TypeScript · Java · SQL
- Backend
- Spring Boot · NestJS
- Frontend
- React · Vite
- Persistence
- PostgreSQL · Spring Data JPA
- Patterns
- DDD · Hexagonal · CQRS · Saga · Outbox · Idempotence
- Operations
- Docker · OpenAPI / Swagger
Trabajar juntos
Si la corrección no es negociable, deberíamos hablar.
Acepto de forma selectiva proyectos donde la arquitectura es lo que importa. El correo es el camino más rápido — leo cada mensaje yo mismo.