DDD lebt – aber Cargo-Cult-DDD ist ein gefährliches Anti-Pattern

Domain-Driven Design (DDD) hat in der Softwareentwicklung einen festen Platz – doch nicht jede Implementierung hält, was sie verspricht. Während echte DDD-Methoden komplexe Domänen strukturieren und Fachsprache präzisieren, verkommt das so genannte Cargo-Cult-DDD oft zu einer leeren Formalität. Doch warum entsteht diese Diskrepanz? Und welche Rolle spielt dabei künstliche Intelligenz?

Warum DDD mehr ist als leere Architektur-Muster

DDD wurde entwickelt, um die Lücke zwischen technischer Umsetzung und geschäftlicher Realität zu schließen. Seine Kernprinzipien – wie die Definition von Bounded Contexts, die Identifikation von Invarianten oder die explizite Modellierung von Zustandsübergängen – zielen darauf ab, Software verständlicher und anpassbarer zu machen. Diese Konzepte gewinnen sogar an Bedeutung, je schneller Code generiert werden kann: Denn unklare Domänenlogik wird in einem solchen Umfeld nicht weniger riskant, sondern deutlich sichtbarer.

Doch genau hier liegt das Problem: Nicht DDD selbst ist überholt, sondern seine oberflächliche Anwendung. Viele Teams reduzieren DDD auf eine Checkliste aus Entities, Value Objects, Repositories und Use Cases – ohne zu hinterfragen, ob diese Strukturen tatsächlich die Fachdomäne abbilden. Statt die Komplexität des Geschäfts zu vereinfachen, dient die Architektur dann nur noch der organisatorischen Kontrolle: Sie macht Entwickler:innen austauschbar, erleichtert die Einarbeitung neuer Mitarbeiter:innen und standardisiert Review-Prozesse.

Der Unterschied zwischen Design für Verständnis und Design für Kontrolle wird dabei oft ignoriert. Während Ersteres darauf abzielt, die fachliche Logik klar abzubilden, dient Zweiteres dazu, Arbeitsabläufe zu vereinfachen – selbst wenn das bedeutet, dass die eigentliche Domänenkomplexität unsichtbar bleibt.

Wenn DDD zur Bürokratie verkommt

Ein Value Object, das keine Invarianten schützt, ein Repository, das nur Datenbankzugriffe maskiert, oder ein Use Case, der keinerlei Geschäftslogik enthält – solche Konstruktionen sind keine Domänenmodelle, sondern architektonische Papierkram-Strukturen. Die Codebasis wird zu einer Sammlung von Platzhaltern:

• - Controller mit leeren Feldern
• - Use Cases ohne echten Geschäftsfall
• - Repositories, die nichts als DAOs mit anderem Namen sind
• - DTOs, die Daten nur kopieren, ohne semantische Grenzen zu definieren
• - Mapper, die Felder verschieben, ohne sie zu interpretieren

Diese Muster mögen kurzfristig die Skalierbarkeit eines Teams erhöhen. Sie ermöglichen es weniger erfahrenen Entwickler:innen, innerhalb klarer Grenzen zu arbeiten, und vereinfachen die Einarbeitung externer Dienstleister. Doch der Preis ist hoch: Die Software verliert an Ausdruckskraft, und die eigentliche Herausforderung – das Verstehen der Fachdomäne – wird umgangen.

Ein besonders tückisches Beispiel sind Bounded Contexts, die nur als technische Grenzen existieren, aber keine fachliche Bedeutung haben. Wenn zwei Kontexte zwar technisch getrennt sind, aber dieselbe Domänenlogik doppelt implementieren, weil die Sprache zwischen Fachbereich und Entwicklung unklar bleibt, dann hat DDD sein Ziel verfehlt. Statt Klarheit zu schaffen, wird die Architektur dann zu einem Hindernis für echte Innovation.

Wie KI die Illusion von Effizienz beschleunigt

Künstliche Intelligenz ist ein mächtiges Werkzeug – besonders bei repetitiven Aufgaben. Genau diese Eigenschaften machen sie jedoch anfällig für die Verstärkung von Cargo-Cult-DDD. Wenn eine Codebasis bereits mit leeren Architektur-Mustern überladen ist, kann KI diese Muster in Rekordzeit reproduzieren:

- Request- und Response-Objekte generieren
- Mapper für Datenumwandlungen erstellen
- Repository-Schnittstellen implementieren
- Use Cases als Hülle für CRUD-Operationen füllen
- Controller nach vorgegebenem Schema anpassen
- Test-Skelette für neue Komponenten erstellen

Die Produktivität steigt – aber nicht, weil die Software besser wird, sondern weil die ohnehin schon bürokratische Architektur schneller umgesetzt werden kann. Entwickler:innen mit weniger Erfahrung können nun noch schneller Code generieren, der formal den DDD-Regeln entspricht, ohne dass die Domäne tatsächlich verstanden wird. Review-Prozesse beschleunigen sich, weil KI strukturelle Vorgaben automatisch einhält. Doch der eigentliche Wert von DDD – die Reduktion von Komplexität durch klares Domänenwissen – bleibt auf der Strecke.

Ein gefährlicher Trugschluss entsteht: Teams beobachten, dass KI die Produktivität steigert, und ziehen daraus den Schluss, dass Entwickler:innen durch KI nicht ersetzt werden können. Doch diese Schlussfolgerung ist oberflächlich. Die eigentliche Frage lautet: Steigert KI die Qualität der Software – oder beschleunigt sie nur die Umsetzung von Architektur-Bürokratie?

Die Zukunft: Von der Kontrolle zur echten Domänenkompetenz

Die Herausforderung der kommenden Jahre wird nicht sein, DDD abzuschaffen, sondern es wieder zu seinem ursprünglichen Zweck zurückzuführen: als Werkzeug für Verständnis und Anpassungsfähigkeit. Dafür müssen Teams umdenken:

• - Architektur sollte nicht der Kontrolle, sondern der Klarheit dienen.
• - Entwickler:innen müssen ermutigt werden, Domänenwissen zu vertiefen – statt nur Code-Schemata zu befolgen.
• - KI sollte nicht zur Beschleunigung von Bürokratie, sondern zur Unterstützung von echten Domänenanalysen eingesetzt werden.

Ein erster Schritt könnte sein, die tatsächlichen Kosten von Cargo-Cult-DDD offen zu legen: veraltete Software, die schwer zu warten ist, weil ihre Architektur keine echte Domänenlogik abbildet. Ein zweiter Schritt wäre, Experimentierräume zu schaffen, in denen Teams alternative Ansätze ausprobieren können – ohne dass sie sich an starre Muster klammern müssen.

DDD wird nicht sterben. Aber sein Wert hängt davon ab, ob es gelingt, es von einer leeren Formalität zu einem echten Gestaltungsprinzip für komplexe Systeme zu machen. Die Alternative – Cargo-Cult-DDD – ist keine Lösung, sondern eine Sackgasse.