Domain-Driven Agents: cómo preparar el código legacy para que los LLM no fallen
Los LLM rinden bien en proyectos nuevos, pero se desploman en bases de código legacy con deuda técnica y acoplamiento. El autor propone que el problema no es el modelo, sino que el código no está listo. Aplica Domain-Driven Design (DDD) para crear un mapa de contextos y glosarios que los agentes puedan consultar, y divide el trabajo en estratégico (decidir) y táctico (implementar). Con manifiestos `.workflow.json` y `CONTEXT.md`, los agentes saben qué términos usar y qué patrones seguir, reduciendo errores. El sistema detecta discrepancias entre declaraciones de bordes de contexto y genera issues automáticamente. El objetivo: que el código responda a las preguntas que el modelo adivina.
El modelo no es lo que necesita una actualización. El código no está listo, y la preparación es algo que podemos construir.
- stephen
También he sido fan de DDD con 'd' minúscula, y hemos tenido suerte con archivos `md` por entidad para documentar de forma independiente del lenguaje el comportamiento, peculiaridades y usos del dominio.
Es decir, un `Author.ts` tiene un `Author.md`, `Book.ts` tiene un `Book.md`.
Para los agentes, les hemos dado una habilidad para leer y escribir los archivos `md`:
https://github.com/joist-orm/joist-orm/blob/main/packages/co...
Y así, las actualizaciones de `md` escritas por agentes aparecen en los PRs. Hasta ahora parece útil (nuestro repositorio principal es un monolito TypeScript de 350k LOC).
Es cierto que esto es mucho menos sofisticado (y menos complicado) que el 'grafo de aristas que entran y salen de cada contexto delimitado' del post original, pero probablemente eso se deba de nuevo a mi preferencia por DDD con 'd' minúscula, donde encuentro que algunos de los patrones de 'DDD a escala' llevan, en mi opinión, a un sobre-diseño.
- owaiswiz
Algo que leí en los primeros párrafos sobre que los LLM son más fáciles de usar en proyectos greenfield...
Mi experiencia ha sido la contraria. Funcionan bien en proyectos existentes, pero no son tan buenos en proyectos nuevos (a menos que solo estés haciendo 'vibe coding' de algo simple).
Creo que tiene que ver con que pueden apoyarse en años de estructura y convenciones establecidas en proyectos existentes, lo que los hace mejores en mi experiencia.
- scotty79
Cuando me preguntaron sobre DDD en una entrevista de trabajo, bromeé diciendo que era Desarrollo Dirigido por Depuración, cuando empiezas con un directorio vacío y registras el primer bug: 'La aplicación no hace nada. Debería...'
Sin ironía, así es más o menos como trabajo ahora con agentes de IA.