Domain-Driven Agents: Wie LLMs in Legacy-Codebasen scheitern und was dagegen hilft
LLMs liefern in Greenfield-Projekten starke Ergebnisse, versagen aber in komplexen Legacy-Codebasen: Sie erfinden neue Schreibweisen für bestehende Konzepte oder treffen falsche Architekturentscheidungen. Der Autor argumentiert, dass nicht das Modell das Problem ist, sondern der Code, dem es an Klarheit und einer gemeinsamen Sprache mangelt. Er zeigt, wie Domain-Driven Design (DDD) mit einem `.workflow.json`-Manifest und Kontext-Glossaren die nötige Präzision liefert, damit Agents effektiv arbeiten können. Strategische Entscheidungen trifft der Mensch, die Umsetzung übernehmen Agents – ein Ansatz, der Tech Debt schneller abbaut.
Das Modell ist nicht das, was ein Upgrade braucht. Der Code ist nicht bereit – und Bereitschaft ist etwas, das wir bauen können.
- stephen
Ich war auch ein Fan von DDD mit kleinem d, und wir hatten Erfolg mit `md`-Dateien pro Entität, um domänenunabhängiges Verhalten, Eigenheiten und Verwendungen zu dokumentieren.
D.h. eine `Author.ts` hat eine `Author.md`, `Book.ts` hat eine `Book.md`.
Für Agents haben wir ihnen eine Fähigkeit gegeben, die `md`-Dateien zu lesen und zu schreiben:
https://github.com/joist-orm/joist-orm/blob/main/packages/co...
Und so tauchen von Agents geschriebene `md`-Updates in PRs auf. Bisher scheint es nützlich zu sein (unser Hauptrepo ist ein TypeScript-Monolith mit 350k LOC).
Zugegeben, das ist viel weniger ausgefeilt (und weniger kompliziert) als der "Graph von Kanten in/aus jedem Bounded Context" im OP, aber das ist wahrscheinlich wieder meine "kleines d"-DDD-Präferenz, bei der ich finde, dass einige der "DDD at Scale"-Muster meiner Meinung nach zu Over-Engineering führen.
- owaiswiz
Etwas, das ich in den früheren Absätzen gelesen habe, über LLMs, die in Greenfield-Projekten einfacher zu handhaben sind...
Meine Erfahrung war das Gegenteil. Sie funktionieren gut bei bestehenden Projekten, sind aber bei neuen nicht so großartig (es sei denn, man macht nur Vibe-Coding mit etwas Einfachem).
Ich denke, es hat etwas damit zu tun, dass sie sich auf jahrelange etablierte Strukturen/Konventionen in bestehenden Projekten stützen können, was sie meiner Erfahrung nach besser macht.
- scotty79
Als ich in einem Vorstellungsgespräch nach DDD gefragt wurde, scherzte ich, es sei Debug Driven Development, wenn man mit einem leeren Verzeichnis beginnt und den ersten Bug meldet: "Die App tut nichts. Sie sollte ..."
Ironiefrei ist das ziemlich genau die Art, wie ich jetzt mit KI-Agents arbeite.