Domain-Driven Design hat in den letzten Jahren viele Anhänger:innen gefunden – und fast genauso viele frustrierte Projektteams hinterlassen. Die Ursachen dafür sind oft dieselben. „Entwickler:innen bauen ihre Entities mit lauter Settern und Gettern", erklärt Dr. Carola Lilienthal. Die Fachlichkeit lande dann irgendwo anders, das Objekt selbst reduziere sich auf einen reinen Datenbehälter. Das widerspricht dem Grundgedanken von DDD fundamental.
Noch folgenreicher ist ein Missverständnis auf der strategischen Ebene: Bounded Contexts werden nicht um fachliche Domänen herum gebaut, sondern um einzelne Aggregate – ein Kundenservice hier, ein Produktservice dort. Das klingt modern, ist aber im Grunde eine serviceorientierte Architektur im DDD-Gewand. Das Ergebnis: jede Menge Abhängigkeiten zwischen den Kontexten, hohe Kopplung, wenig Kohäsion. Genau das, was man eigentlich vermeiden wollte.
Dahinter steckt oft ein tief verwurzelter Reflex: Wiederverwendung. „Uns ist beigebracht worden, dass wir Reuse machen sollen", sagt Carola. In DDD-Architekturen darf es die Klasse „Kunde" aber durchaus mehrfach geben – jeweils kontextspezifisch, kleiner und präziser zugeschnitten. Das erfordert ein echtes Umdenken, einen „Shift im Kopf", wie sie es nennt.
Wer DDD konsequent umsetzt, begegnet früher oder später auch der Frage nach technischen Schulden. Die simpelste Gegenmaßnahme? Unit-Tests. „Wenn man einzelne Klassen testet, hat man die Tendenz, sie nicht zu groß werden zu lassen", so Carola. Fast automatisch entstehen entkoppeltere, besser wartbare Strukturen. Eine Testabdeckung von rund 80 Prozent sei ein realistisches und wirkungsvolles Ziel. Ergänzend helfen Metrik-Tools wie SonarQube, die Hotspots sichtbar machen: große Klassen, breite Schnittstellen, hohe Kopplung. Für komplexere Systeme empfiehlt sie zusätzlich echte Architektur-Reviews mit spezialisierten Tools – um zu verstehen, wie das System wirklich aufgebaut ist, nicht nur wie es sein sollte.
Ein drittes großes Thema: Führung im KI-Zeitalter. Auch hier hat die Expertin aus der eigenen Praxis gelernt. Tech Leads, die wollen, dass ihre Teams KI-Tools sinnvoll nutzen, müssen die Technologie selbst verstehen und ausprobieren. Gleichzeitig beobachtet sie, dass Entwickler:innen ihren Entdeckerdrang jetzt auf KI-Tools richten – sie wollen herumknobeln, experimentieren, etwas zum Laufen bringen. „Softwareentwickler:innen denken nicht im ersten Moment ans Zeitsparen, die lieben es, etwas hinzukriegen." Das sei per se nichts Schlechtes, brauche aber Führung: Jemanden, der den Spaß an der Technologie erhält, aber gleichzeitig sicherstellt, dass die Experimente dem Team wirklich nützen – und dass am Ende auch die bezahlte Arbeit erledigt wird.
Die Expertin spricht auf der DWX 2026 in Mannheim – wer die Themen vertiefen will, sollte sich ein Ticket sichern.
Dr. Carola Lilienthal studierte Informatik an der Universität Hamburg und promovierte 2008 in Informatik bei Christiane Floyd und Claus Lewerentz an der Universität Hamburg. Carola ist Geschäftsführerin der WPS – Workplace Solutions GmbH und verantwortet dort den Bereich Softwarearchitektur. Seit 2003 analysiert Dr. Carola Lilienthal in ganz Deutschland Architekturen in Java, C#, C++, ABAP und PHP und berät Entwicklungsteams, wie sie die Langlebigkeit ihrer Softwaresysteme verbessern können. 2015 hat sie ihre Erfahrungen aus über hundert Analysen in dem Buch „Langlebige Softwarearchitekturen“ zusammengefasst.
📅 DWX 2026, 29. Juni bis 2. Juli 2026, Mannheim 🔗 https://www.developer-world.de/dwx
