Artículos sobre arquitectura, testing y buenas prácticas de desarrollo backend.
20 artículos
Una mejor decisión técnica rara vez es la que elige la tecnología más brillante. Es la que entiende el problema real, hace explícitas las restricciones, compara opciones honestamente y deja por escrito por qué se eligió. Decidir bien es un proceso, no un golpe de intuición.
Se supone que un pasatiempo debe alejarte del trabajo. El mío se parece a trabajar gratis: escribir código open source. Esta es la historia de dmx-fun, una biblioteca de programación funcional para Java que empecé hace un año, y de por qué construirla es descanso y no obligación.
Identificar bounded contexts no es dibujar cajas en un diagrama ni partir el sistema por tablas. Es encontrar las fronteras donde el lenguaje cambia de significado. Esas costuras ya existen en cómo habla el negocio; el trabajo es escucharlas, no inventarlas.
Añadimos capas por reflejo, convencidos de que separar es siempre desacoplar. Pero una capa que solo reenvía datos de una a otra no aísla nada: agrega ceremonia, costo de navegación y la ilusión de un diseño limpio. Una capa solo se gana su lugar cuando absorbe un cambio que de otro modo se propagaría.
Diseño y arquitectura se usan como sinónimos, pero no lo son. La distinción no está en el tamaño del diagrama ni en el cargo de quien decide, sino en el costo de cambiar una decisión. Entender esa diferencia cambia cómo inviertes tu atención y qué peleas vale la pena dar temprano.
La complejidad técnica no solo se paga en latencia, bugs y horas de mantenimiento. Se paga en personas: en la carga cognitiva que erosiona la atención, en el miedo a tocar el código, en el conocimiento que se concentra en pocas cabezas y en la lenta fuga de la gente que ya no aguanta.
Detrás de buena parte de las arquitecturas distribuidas no hay un requisito técnico, sino una estructura organizacional que se volvió código. Cuando un equipo divide un sistema en servicios, muchas veces no está resolviendo un problema de escala — está reproduciendo sus propias fronteras de comunicación.
El seniority no se mide en años de experiencia ni en la cantidad de tecnologías que conoces. Se mide en la calidad de tus decisiones, en el impacto que tienes sobre las personas a tu alrededor, y en la capacidad de navegar ambigüedad sin perder el rumbo.
Las organizaciones diseñan sistemas que son copias de su estructura de comunicación. La Ley de Conway no es una curiosidad histórica — es una fuerza activa que moldea tu arquitectura, tu documentación, tus planes de carrera y cómo fluye la información dentro de tu empresa.
El error más común al adoptar Domain-Driven Design es creer que se trata de anotar clases con @Entity y modelar tablas en objetos. DDD es una disciplina de diseño estratégico, y las entidades son apenas una pieza menor del rompecabezas.
La regla 'usa BigDecimal para dinero y finanzas' está tan arraigada que dejamos de cuestionarla. Un issue abierto en una librería de finanzas cuantitativas me obligó a replantearme el dogma.
Prueba lo que te puede romper en producción, no solo lo que es fácil de testear. El 80% de los bugs vienen de integración, configuración, datos y concurrencia — exactamente lo que el unit test aislado no cubre. Una guía práctica de testing por capas.
Los ADRs son una práctica simple pero poderosa para capturar las decisiones arquitectónicas de un sistema. No se trata de documentación burocrática, sino de preservar el contexto que hace comprensible la arquitectura a lo largo del tiempo.
La deuda técnica no es el enemigo. El problema es ignorarla. Cómo balancear entrega continua con salud técnica sin paralizarte ni resignarte.
Si actualizas la base de datos y luego notificas a sistemas externos, hazlo con outbox. Guardar en DB y luego mandar falla en el peor momento: guardaste, no enviaste, nadie sabe, y ya no puedes reconstruir.
El mérito técnico aislado no garantiza adopción. Una pieza de tecnología puede ser excelente en abstracto y aun así fracasar si no encaja con el resto del mundo. Por qué el ecosistema no es un detalle de implementación, sino parte central del diseño.
Hace más de 16 años viví una de las experiencias profesionales que más me han marcado: despedir a mi equipo por falta de presupuesto, y luego verlos regresar cuando la empresa se recuperó. Una historia de confianza, liderazgo y resiliencia.
Si no lo puedes medir, no lo puedes operar. El bug más caro es el que no puedes reproducir. Observabilidad no es ver que falló, es entender por qué y cómo. Una guía práctica de logs estructurados, métricas que importan y trazas distribuidas.
Orquestación vs coreografía no es una pelea filosófica, es una decisión de operabilidad y control de fallas. Si tu proceso tiene alto costo de error, muchas ramas o necesita auditoría: orquesta. Si tu sistema vive de extensiones por eventos y el flujo es simple: coreografía.
10 principios prácticos que uso para diseñar backends Java que aguantan producción. No es una religión. Es una lista de decisiones que reducen sorpresas.
