Wenn dein KI-Assistent Gedanken lesen soll

Mal ehrlich: Wer von uns hat nicht schon mal genervt vor seinem KI-Coding-Assistenten gesessen? Du beschreibst eine Funktion, und was kommt raus? Technisch funktioniert es ja, aber es verfehlt komplett den Kern. Generische Klassennamen. Logik überall verteilt in Hilfsklassen. Null Respekt für die Geschäftsregeln, die deine Anwendung eigentlich besonders machen.

Hier die unbequeme Wahrheit: Die KI ist nicht das Problem. Du bist es.

Nicht um zu schuldigen – sondern rein praktisch. KI-Sprachmodelle sind fantastisch im Pattern-Matching und Codegenerierung, aber sie sind begrenzt durch das, was du ihnen gibst. Vager Kontext rein, vager Code raus. Mehrdeutige Anweisungen rein, mehrdeutiges Verhalten raus.

Und genau hier kommt Domain-Driven Design ins Spiel – und ja, es ist das Beste, was KI-gestützter Entwicklung seit Autocomplete passiert ist.

Was DDD wirklich ist (ohne akademischen Overload)

Ich kenne den Gedanken: "DDD? Das ist doch diese schwere Methodik mit den 47 Patterns und dem 800-Seiten-Bibel, oder?"

Jein.

DDD basiert auf einer Wette darüber, wo die Komplexität in Software wirklich steckt. Die Prämisse: Bei den meisten Anwendungen ist das Schwierige nicht die Technologie – es ist das Verständnis und die Modellierung der Domain. Die Geschäftsregeln. Die Fachbegriffe, die hier etwas Bestimmtes bedeuten, aber woanders etwas ganz anderes. Die Edge Cases, die nur im richtigen Kontext Sinn ergeben.

DDD sagt deshalb: Stell ein Modell deiner Domain in den Mittelpunkt deiner Arbeit. Drück es in einer Sprache aus, die Entwickler UND Fachabteilungen verstehen. Der Code soll dieses Modell direkt abbilden.

Der strategische Part kümmert sich ums große Ganze: eine geteilte Fachsprache etablieren (die sogenannte Ubiquitous Language) und Grenzen definieren (Bounded Contexts), innerhalb derer diese Sprache konsistent bleibt.

Der taktische Part kümmert sich um die Bausteine: Entities mit Identität, Value Objects, die durch ihre Attribute definiert sind, Aggregates, die zusammengehörige Objekte gruppieren, und Domain Events, die bedeutsame Änderungen erfassen.

Ein Anti-Pattern, auf das du achten solltest – und das auch erfahrene Entwickler immer wieder erwischt – ist das "Anemic Model". Das sind Objekte, die nur Datencontainer mit Gettern und Settern sind, während die gesamte Logik in separaten Service-Klassen lebt. DDD stellt sich quer: Das Verhalten gehört dorthin, wo die Daten sind.

Warum das für KI-Coding-Assistenten wichtig ist

Jetzt wird's spannend für uns in 2024 und darüber hinaus.

KI-Sprachmodelle sind im Grunde Pattern-Completion-Engines auf Steroiden. Sie sagen voraus, wie Code aussehen sollte, basierend auf dem, was sie im Training gesehen haben. Und hier liegt das Problem: Die Trainingsdaten sind voll von anämischen CRUD-Patterns, generischer Benennung und verstreuter Logik. Das ist der Weg des geringsten Widerstands in den meisten Codebasen – also das, worauf die Modelle standardmäßig zurückfallen.

Wenn du DDD-Prinzipien anwendest, gibst du der KI praktisch Leitplanken, die sie zu besseren Ergebnissen lenken. Jedes DDD-Artefakt, das du erstellst, wird zum Prompt-Material. Jede Entscheidung, die du explizit machst, wird zur Einschränkung, innerhalb derer die KI arbeiten kann.

Lass mich durch die vier Bereiche gehen, wo das am meisten zählt:

1. Eure geteilte Fachsprache wird zum System-Prompt der KI

Stell dir vor: Du baust ein Abonnement-Verwaltungssystem. Dein Team hat sich geeinigt, dass "Abonnement", "Plan" und "Berechtigung" ganz bestimmte Dinge bedeuten. Ein Abonnement ist eine aktive Beziehung zwischen einem Kunden und einem Plan. Ein Plan definiert, was verfügbar ist. Eine Berechtigung ist das, was der Kunde tatsächlich nutzen darf.

Wenn du User Stories oder Feature-Beschreibungen mit diesen präzisen Begriffen schreibst, kann die KI diese Fachsprache verinnerlichen. Wenn du sie bittest, eine Funktion für "Abonnements upzugraden" hinzuzufügen, generiert sie Code, der diese Unterscheidungen respektiert. Sie wird "Plan" und "Berechtigung" nicht vermischen, weil du explizit warum ihre separaten Rollen.

Dieses Glossar, das du für die Einarbeitung neuer Entwickler pflegst? Es ist auch genau das, was die KI braucht. Dieselbe Information, doppelter Nutzen.

2. Bounded Contexts halten KI-Sessions fokussiert

Schon mal versucht, eine KI bei einem Feature zu helfen, das sechs verschiedene Teile deines Systems berührt? Die Ergebnisse sind meistens chaotisch – halbfertige Änderungen, übersehene Abhängigkeiten, Logik, die sich über Module hinweg widerspricht.

Bounded Contexts lösen das ganz natürlich. Jeder Context ist ein definierter Bereich, in dem ein bestimmtes Modell und eine bestimmte Sprache gelten. Wenn du im "Billing"-Context arbeitest, bedeutet der Begriff "Account" möglicherweise etwas anderes als im "User Management"-Context. Das ist in Ordnung, solange die Grenzen klar sind.

Für KI-Workflows passt das wunderbar zu fokussierten Sessions. "Heute arbeiten wir im Order Fulfillment Context. Hier sind seine Fachbegriffe und Regeln. Den Inventory Context ignorieren wir erstmal." So bringst du das Modell dazu, on-target zu bleiben, statt sich durch dein ganzes System auszubreiten.

3. Verhaltensreiche Modelle schützen deine Geschäftsregeln

Das ist der praktische Sicherheitsvorteil, der oft übersehen wird.

Wenn du Geschäftsregeln in die Objekte einbaust, die die relevanten Daten besitzen, gibt es einen Ort, sie zu bewachen. Wenn du diese Regeln über mehrere Service-Klassen verteilst, kann jeder generierte Code-Code sie versehentlich umgehen.

Nimm eine Bestellvalidierungsregel: Eine Bestellung kann nicht versendet werden, wenn die Zahlung nicht eingegangen ist. Wenn diese Regel in Order.Ship() lebt, ist sie geschützt. Jeder Code, der versucht, eine unbezahlte Bestellung zu versenden, geht durch diese Prüfung. Aber wenn die Regel in einem separaten ShippingService lebt, könnte eine KI fröhlich einen neuen ShippingProcessor generieren, der Bestellungen ohne Zahlungsprüfung versendet.

Verhaltensreiche Modelle konzentrieren deine Invarianten an Stellen, wo sie das System wirklich schützen können.

4. Tests werden zu ausführbaren Spezifikationen

DDDs Betonung auf Invarianten – Regeln, die immer gelten müssen – übersetzt sich direkt in Testfälle. "Ein Abonnement kann nicht verlängert werden, nachdem es gekündigt wurde." "Ein Benutzer kann nicht mehr Guthaben übertragen, als er hat." "Eine Bestellung kann nicht an eine unvollständige Adresse versendet werden."

Das sind nicht nur gute Tests. Das ist eine Definition von Korrektheit, mit der eine KI arbeiten kann. Schreib sie zuerst, und die KI hat ein konkretes Ziel, auf das sie hinarbeiten kann. Sie kann die Tests ausführen und sofort wissen, ob sie auf dem richtigen Weg ist. Das ist wesentlich zuverlässiger, als darauf zu hoffen, dass sie Prosa-Beschreibungen von Geschäftsregeln korrekt befolgt.

Die Fallen, die du beachten musst**

Ich will ehrlich sein: DDD mit KI anzuwenden ist kein automatischer Zauber. Die Standardeinstellungen arbeiten in manchen Bereichen gegen dich.

Die KI defaultet zu anämischem CRUD. Wenn du um "eine Customer-Klasse" bittest, kriegst du oft ein öffentliches Getter/Setter-Paar, während die gesamte Logik in einen separaten Service verbannt wird. Du musst explizit um Verhalten auf dem Objekt bitten, um private Setter und um Logik, die bei den Daten bleibt, die sie schützt.

Die KI erfindet Vokabular. Du sagst "Bestellung", sie schreibt "Transaktion". Du sagst "Abonnement", sie schreibt "Mitgliedschaft". Das sind in deiner Domain keine Synonyme, aber die KI weiß das nicht,除非 du es ihr sagst. Konsistentes, explizites Vokabular in deinen Prompts hilft – aber genauso das Unterbringen dieser Begriffe in Dateinamen, Klassennamen und Kommentaren, wo die KI sie natürlich aufgreift.

Die KI über-engineert bei Unsicherheit. Wenn eine KI keine klare Orientierung über das richtige Komplexitätsniveau hat, fällt sie oft auf ausgefeilte Patterns zurück – Abstract Factories, übermäßige Interfaces, unnötige Schichten. DDD bietet hier eine nützliche Heuristik: Nutze die teuren Patterns (Aggregates, Domain Events, Bounded Contexts) nur, wenn die Domain-Komplexität sie rechtfertigt. Für einfachere Domains reichen vielleicht verhaltensreiche Klassen mit klaren Namen völlig aus.

Die praktische Erkenntnis**

Hier meine ehrliche Einschätzung nach all dem Überlegen: DDD ist nicht mehr in erster Linie eine Coding-Methodik. Es ist eine Kontext-Engineering-Methodik für das KI-Zeitalter.

Jede DDD-Praxis, die du adoptierst, macht deine Domain expliziter – und explizit ist genau das, worauf Sprachmodelle reagieren können. Die geteilte Fachsprache, die du für dein Team aufbaust, wird zur Sprache, die die KI verwendet. Die Bounded Contexts, die du ziehst, werden zu natürlichen Arbeitseinheiten für fokussierte KI-Sessions. Die verhaltensreichen Modelle, die du erstellst, werden zu geschützten Bereichen, wo Geschäftsregeln nicht stillschweigend umgangen werden können.

Du hättest diese Arbeit sowieso gemacht, wenn du wartbare Software wolltest. Jetzt zahlt sie sich auch mit KI-Assistenten aus.

Die günstigen Teile von DDD – Sprachklarheit und Verhaltenskonzentration – gelten überall. Die teuren Teile – vollständige taktische Patterns, elaborates Event Sourcing – gelten nur dort, wo die Domain-Komplexität sie wirklich rechtfertigt.

Fang mit den günstigen Teilen an. Mach das Vokabular explizit. Bring Verhalten zu den Daten. Halte Grenzen klar. Dann lass die KI dir beim Rest helfen.

Dein zukünftiges Ich, das um 2 Uhr nachts Code debuggt, wird dir danken. Und die KI, die es tatsächlich schafft zu helfen statt zu hindern.