Neuigkeiten von trion.
Immer gut informiert.

Domain-Driven Design und KI: die KI-Integration hinter einem Anti-Corruption Layer

Fachdomäne und externes LLM, getrennt durch einen Anti-Corruption Layer

Domain-Driven Design und generative KI werden oft getrennt betrachtet. Das eine gilt als Methodik für fachliche Modellierung, das andere als Technologiethema. Tatsächlich berühren sich beide an mehreren Stellen, und die Verbindung ist tragfähiger, als es auf den ersten Blick wirkt.

In diesem Beitrag ordnen wir die Schnittmengen ein und trennen dabei zwei Richtungen, die man nicht vermischen sollte.

Richtung 1: DDD als Methode, um KI-Systeme zu bauen

Das ist die belastbarere Verbindung, weil Domain-Driven Design genau die Probleme adressiert, die LLM-Anwendungen schwierig machen. LLMs und Agenten bringen Nichtdeterminismus, Halluzinationen und unscharfe Grenzen zwischen Daten, Steuerung und Logik in ein System. Ohne klare Architektur sickern diese Eigenschaften in die Fachlogik ein.

Der zentrale Gedanke: Das LLM ist ein externes, nichtdeterministisches System und wird wie ein Fremddienst über einen Anti-Corruption Layer an den eigenen Kontext angebunden. So bleibt der nichtdeterministische Teil gekapselt, statt sich im Domänenmodell auszubreiten. Nicht das LLM selbst ist dabei der Bounded Context, sondern der Teil des Systems, der die KI-Integration kapselt und ihr ein eigenes Modell gibt. Die Übersetzung zwischen KI-Ausgaben und Domänenmodell findet an einer klar definierten Grenze statt, inklusive Fehlerbehandlung und Rückfallebenen.

Auch die taktischen Muster lassen sich übertragen. Tools und Function Calling sind nichts anderes als Domänenoperationen, die einem Agenten kontrolliert zur Verfügung gestellt werden. Strukturierte Ausgaben bilden sich natürlich auf Commands und Value Objects ab. Aggregate und Invarianten liefern die Guardrails dafür, was ein Agent überhaupt auslösen darf.

Die Ubiquitous Language spielt dabei eine doppelte Rolle. Ein konsistentes Domänenvokabular verbessert Prompts und Retrieval messbar. Das Glossar wird zum geteilten Artefakt, das Fachdomäne und KI-Kontext verbindet, und die Wissensbasis für Retrieval-Augmented Generation lässt sich entlang der Bounded Contexts strukturieren.

Strategisch hilft die Einteilung in Core-, Supporting- und Generic-Subdomains bei einer Frage, die bei KI-Features regelmäßig auftaucht: selbst bauen oder einkaufen. Ist die KI-Funktion ein Differenzierungsmerkmal oder eine Standardfähigkeit? Die Subdomain-Klassifikation ist genau das Entscheidungswerkzeug dafür.

Richtung 2: KI als Werkzeug im DDD-Prozess

Hier ist der Nutzen real, aber die Grenze klar.

KI trägt gut bei den mechanischen Teilen der Modellierungsarbeit. Große Altcodebasen lassen sich mit LLMs analysieren, um das implizite Domänenmodell zu rekonstruieren und Kontextgrenzen zu finden. Aus Anforderungen, Transkripten und Code lässt sich die Ubiquitous Language extrahieren und konsolidieren. Event-Storming-Workshops lassen sich nachbereiten, indem Transkripte geclustert und Kandidaten für Events, Commands und Aggregate vorgeschlagen werden. Und aus einem bestehenden Modell lassen sich die taktischen Bausteine als Codegerüst generieren.

Nicht ersetzen kann KI das eigentliche Knowledge Crunching zwischen Entwicklern und Fachexperten. Wer das Modell vom LLM generieren lässt, bekommt plausible, aber oft falsche Domänenregeln. Vor allem geht der Effekt verloren, den Domain-Driven Design stiften soll: das geteilte Verständnis im Team. KI beschleunigt die Modellierung, sie ersetzt sie nicht.

Klare Sprache und Strukturen machen Code KI-tauglich

Ein LLM arbeitet umso besser, je weniger es raten muss. Es braucht eindeutige Begriffe und eine erkennbare Struktur, um korrekten und zur Fachlichkeit passenden Code zu erzeugen. Genau das liefert Domain-Driven Design: die Ubiquitous Language macht die Fachbegriffe explizit, und Bounded Contexts, Aggregate und klare Schichten geben dem Code eine nachvollziehbare Ordnung.

In einer gut modellierten Domäne findet ein Agent benannte Konzepte statt generischer Hilfskonstrukte und klare Grenzen statt diffuser Abhängigkeiten. Das reduziert Mehrdeutigkeit und verbessert die Qualität der Vorschläge spürbar. Umgekehrt findet die KI in einem impliziten, uneinheitlichen Modell dieselbe Unschärfe vor, die auch Menschen die Arbeit erschwert, und liefert entsprechend schlechtere Ergebnisse.

Gute Modellierung zahlt sich damit doppelt aus. Ein nach Domain-Driven Design strukturiertes System ist nicht nur für Menschen wartbar, sondern auch für KI-Werkzeuge gut zugänglich.

Fazit

Die Verbindung von Domain-Driven Design und KI ist kein Marketingkonstrukt. Als Architekturmethode für KI-Systeme ist DDD besonders tragfähig, weil der Anti-Corruption Layer um nichtdeterministische Komponenten ein echtes Problem löst. Im Modellierungsprozess selbst ist KI ein nützliches Werkzeug für die mechanischen Teile, nicht für die fachliche Kernarbeit. Und je klarer eine Domäne modelliert ist, desto besser können KI-Werkzeuge mit ihrem Code arbeiten, gute Modellierung zahlt sich damit gleich doppelt aus.

Wir vertiefen diese Themen in unseren Schulungen zu Domain-Driven Design und KI:

Feedback oder Fragen zu einem Artikel - per E-Mail an [email protected] oder über das Kontaktformular. Wir freuen uns auf eine Kontaktaufnahme!

Suche

Los geht's!

Bitte teilen Sie uns mit, wie wir Sie am besten erreichen können.