El torno no le dice al maquinista dónde poner el eje. El osciloscopio no le dice al ingeniero eléctrico por dónde rutear la señal. La grúa no le dice al ingeniero civil dónde poner las paredes. Toda disciplina de ingeniería madura lo entendió pronto y no miró atrás: el problema físico guía el diseño. Las herramientas son medios, no fines.

El software fue la excepción — y por un tiempo sorprendentemente largo.

I. El desvío de cuarenta años

Durante las primeras cuatro décadas del software comercial, la tecnología guiaba el diseño. No el problema. “Estamos construyendo esto en Java, así que tendremos clases, interfaces, factories, managers.” “Hacemos microservicios, entonces la estructura del equipo sigue la topología de servicios.” “Usamos base de datos relacional, entonces el modelo de dominio sigue el esquema.” El martillo determinaba la forma de la casa.

El libro Domain-Driven Design de Eric Evans, publicado en 2003, es esencialmente el campo del software poniéndose al día con lo que los ingenieros mecánicos sabían antes de la Revolución Industrial. El dominio es el conductor. La tecnología es el medio. Construyes un lenguaje ubicuo alrededor del problema de negocio, no alrededor del ORM. Defines contextos acotados alrededor de lo que el negocio necesita, no alrededor de lo que es técnicamente conveniente desplegar. Diseñas agregados alrededor de invariantes de negocio, no alrededor de las reglas de normalización de la base de datos.

Un ingeniero mecánico que levantara el libro de Evans lo encontraría desconcertante — no difícil, sino desconcertante. Por supuesto que el problema físico guía el diseño. ¿Qué otra cosa lo guiaría? Pero los ingenieros de software pasaron cuarenta años dejando que ocurriera lo contrario, y DDD fue el correctivo que tuvo que escribirse, formalizarse, debatirse en conferencias, convertirse en 560 páginas, porque el campo había perdido genuinamente el hilo.

II. Por qué el software perdió el hilo

Tres razones estructurales, ninguna accidental.

La primera es el problema de la maleabilidad. El software no tiene física. Puedes refactorizar, reescribir, reestructurar a voluntad. El metal se fatiga. Los puentes colapsan. El código simplemente sigue corriendo hasta que lo borras. Sin restricciones físicas que impongan corrección, las restricciones se sienten artificiales — negociables — y se negocian a favor de lo que la herramienta o el paradigma actual hace fácil. La conveniencia llena el vacío que la física dejó.

La segunda es el problema de la visibilidad. En software, las herramientas están hechas del mismo material que lo que estás construyendo. El código que implementa un patrón factory es indistinguible, en sustancia, del código que implementa la lógica de negocio. No hay una línea obvia entre el martillo y el clavo. Cuando el andamio y el edificio se ven idénticos, es fácil olvidar cuál es cuál.

La tercera es el problema de la juventud. La ingeniería mecánica tiene miles de años. La ingeniería civil se remonta a Roma y más allá. La ingeniería eléctrica tiene unos 150 años. El software tiene 80. Las disciplinas acumulan lecciones duras lentamente — a través de fallas, litigios, estructuras colapsadas, ciudades incendiadas — y luego las codifican en estándares, requisitos de licencia, normas profesionales. El software sigue acumulando las lecciones de su primer siglo.

III. La pregunta incómoda

Evans publicó su diagnóstico en 2003. Estamos en 2026 y el argumento no ha terminado.

Las arquitecturas de microservicios se siguen diseñando alrededor de la conveniencia del despliegue — lo que Kubernetes hace fácil de ejecutar — en lugar de alrededor de los límites del dominio. Las integraciones con LLMs se están construyendo alrededor de la superficie de API del modelo, sus límites de tokens, su interfaz de herramientas, en lugar de alrededor del problema de negocio que el modelo supuestamente debe resolver. El patrón no ha cambiado; solo la tecnología.

Si DDD ya era obvio en 2003, ¿por qué cada nueva tecnología reinicia el reloj? ¿Por qué cada generación de ingenieros comete el mismo error con herramientas nuevas?

La respuesta más honesta es que el sesgo hacia la herramienta no es un error corregible. Es una característica estructural de cómo se construye el software. La nueva tecnología llega con su propia API, su propio modelo mental, su propia comunidad de adoptadores tempranos entusiastas que han construido su identidad alrededor de ella. Aprender la herramienta es rápido. Aprender el dominio es lento, costoso y poco glamoroso. Los incentivos apuntan todos en la misma dirección: entender la tecnología, aproximar el dominio.

IV. Diagnóstico sin cura

Evans no resolvió esto. Lo nombró. DDD nunca fue una metodología que, una vez adoptada, corregiría la deriva subyacente. Fue un recordatorio — un argumento de 560 páginas de que el dominio es real y la herramienta no — escrito porque ese recordatorio necesitaba existir.

En México, en Colombia, en Argentina, el título de ingeniero no es una declaración informal: se obtiene de una universidad acreditada y en muchos países se registra ante un colegio profesional. El ingeniero civil que firma un plano está poniendo su matrícula en juego. El software no tiene equivalente. Te declaras arquitecto de software y diseñas el sistema alrededor de la tecnología que te entusiasma este año. No hay colegio profesional, no hay responsabilidad civil, no hay puente colapsado que haga legible el error.

Quizás esa es la lección más profunda. DDD tiene razón sobre lo que debería guiar el diseño. Pero debería hace mucho trabajo pesado en un campo que ha evitado sistemáticamente las estructuras de accountability que harían que ese “debería” significara algo.

El dominio se reafirma eventualmente — a través de costos de mantenimiento, de migraciones fallidas, de sistemas tan enredados en sus propios idiomas técnicos que nadie puede explicar qué hacen realmente. Esa es la física que sí tiene el software: no restricciones materiales, sino el costo compuesto de la deuda técnica. No mata a nadie. Solo hace todo más difícil, más lentamente, hasta que el proyecto se reescribe.

Y la reescritura empieza con la misma conversación de siempre: ¿qué problema estamos resolviendo realmente?

Lecturas adicionales