Die meisten Entwickler glauben, dass sie Architektur betreiben, wenn sie Ordnerstrukturen nach Entitäten benennen oder Repositories für ihre Datenbankzugriffe bauen. Sie sitzen in sterilen Büros, starren auf Bildschirme und versuchen, die Welt in Code zu pressen. Doch genau hier liegt der fundamentale Irrtum begraben, der Milliarden an Euro in gescheiterten IT-Projekten versenkt. Es geht bei Domain Driven Design Eric Evans nämlich gar nicht primär um Software. Wer das dicke blaue Buch aufschlägt, erwartet technische Rezepte, findet aber stattdessen eine Abhandlung über Sprache und zwischenmenschliche Kommunikation. Wir haben uns angewöhnt, Softwareentwicklung als ein reines Übersetzungsproblem zu betrachten: Business-Anforderungen rein, Code raus. Das ist falsch. Es ist kein Übersetzungsprozess, sondern ein gemeinsamer Entdeckungsprozess, bei dem die Technik oft die unwichtigste Rolle spielt. Wenn wir über dieses Feld sprechen, reden wir über die schmerzhafte Erkenntnis, dass Code nur so gut sein kann wie das Verständnis der Domäne, die er abbilden soll. Die Branche hat daraus ein Set von technischen Mustern gemacht, doch wer nur die Muster kopiert, hat den Kern der Sache schlichtweg nicht begriffen.
Die Illusion der technischen Lösung
Es herrscht eine seltsame Arroganz in der Welt der Softwarearchitektur. Wir glauben, dass wir mit dem richtigen Framework oder der neuesten Cloud-Technologie jedes Problem lösen können. Ich habe Teams gesehen, die monatelang über Microservices diskutiert haben, ohne auch nur eine Stunde mit den Menschen zu sprechen, die ihre Software tatsächlich benutzen. Sie bauen glänzende Kathedralen aus Code auf einem Fundament aus purem Unverständnis. Das Problem ist, dass fachliche Logik meistens chaotisch, widersprüchlich und historisch gewachsen ist. Kein Algorithmus der Welt kann die Nuancen einer deutschen Versicherungsrechnung oder die Logik einer globalen Lieferkette allein durch technische Eleganz einfangen.
Hier stoßen wir auf die erste unbequeme Wahrheit. Software scheitert fast nie an der Technik. Sie scheitert an der Sprache. Wenn der Fachbereich von einem Kunden spricht, meint er vielleicht den Rechnungsempfänger. Der Entwickler denkt jedoch an einen Datensatz in der Tabelle Users. Diese Diskrepanz wirkt am Anfang klein. Nach zwei Jahren Entwicklung führt sie dazu, dass das System unter seinem eigenen Gewicht zusammenbricht, weil jede Änderung an einer Stelle unvorhersehbare Konsequenzen an zehn anderen Stellen hat. Das ist kein Mangel an Clean Code. Es ist ein Mangel an begrifflicher Schärfe.
Domain Driven Design Eric Evans und die Macht der Sprache
Was viele als akademische Spielerei abtun, ist in Wahrheit eine radikale Methode zur Komplexitätsbewältigung. Wenn wir von Domain Driven Design Eric Evans sprechen, meinen wir den Versuch, eine Brücke über den Abgrund zwischen Fachlogik und Implementierung zu schlagen. Der Schlüsselbegriff hierbei ist die allgegenwärtige Sprache. Es reicht nicht aus, wenn Entwickler die Begriffe des Fachbereichs kennen. Die Sprache muss im Code leben. Jede Variable, jede Methode und jedes Modul muss genau so heißen wie das Konzept im Kopf des Fachexperten.
Der Verrat durch die Abstraktion
Oft neigen wir dazu, alles zu verallgemeinern. Wir bauen eine Klasse Product, die alles kann, vom Preis bis zur Lagerhaltung. Das klingt effizient, ist aber brandgefährlich. In der Realität bedeutet ein Produkt für den Verkauf etwas völlig anderes als für den Versand. Im Verkauf ist der Preis entscheidend. Im Versand ist es das Gewicht und die Abmessung. Wenn wir versuchen, diese beiden Welten in ein einziges Modell zu zwingen, schaffen wir ein Monster. Die wahre Kunst besteht darin, Grenzen zu ziehen. Wir müssen akzeptieren, dass dasselbe Wort in unterschiedlichen Kontexten unterschiedliche Bedeutungen hat. Diese Erkenntnis ist der Kern der sogenannten Bounded Contexts. Es ist die Kapitulation vor der Idee, dass es ein einziges, alles umfassendes Datenmodell geben kann. Wer das verstanden hat, hört auf, nach der perfekten Datenbanktabelle zu suchen. Er fängt an, nach den Grenzen der Bedeutung zu suchen.
Die Angst vor der fachlichen Tiefe
Warum wehren sich so viele Teams gegen diesen Ansatz? Es ist anstrengend. Es erfordert, dass Entwickler sich für die langweiligen Details von Buchhaltungsprozessen oder Logistikketten interessieren. Es ist viel bequemer, sich hinter Jira-Tickets und technischen Spezifikationen zu verstecken. Viele Programmierer sehen sich als Handwerker, die fertige Entwürfe umsetzen. Doch in einer komplexen Welt gibt es keine fertigen Entwürfe. Wer nicht bereit ist, die Domäne tiefgreifend zu durchdringen, wird immer nur oberflächliche Lösungen produzieren.
Skeptiker führen oft an, dass dieser Weg viel zu zeitaufwendig sei. Man müsse erst einmal liefern, heißt es dann oft in den Projektmeetings. Refactoring und endlose Sprachdiskussionen würden den Release verzögern. Das ist ein kurzsichtiges Argument. Ja, der Anfang ist langsamer. Man verbringt Stunden damit, über die präzise Bedeutung eines einzelnen Wortes zu streiten. Doch dieser Zeitinvest zahlt sich tausendfach aus, sobald die erste große Änderung kommt. Ein System, das die Fachlichkeit präzise widerspiegelt, lässt sich fast ohne Reibung anpassen. Ein System, das auf falschen Annahmen und technischem Kauderwelsch basiert, wird mit jeder neuen Funktion instabiler. Wir bauen uns technische Schulden nicht durch schlechten Code auf, sondern durch schlechte Modelle. Die Kosten für ein missverstandenes Geschäftsmodell im Kern der Software sind astronomisch höher als die Kosten für ein paar zusätzliche Meetings zu Projektbeginn.
Warum Domain Driven Design Eric Evans keine Architektur ist
Wir müssen mit dem Missverständnis aufräumen, dass es sich hierbei um eine Blaupause für Softwarearchitektur handelt. Es ist vielmehr eine Philosophie der Zusammenarbeit. Die technischen Werkzeuge wie Entities, Value Objects oder Aggregates sind nur Hilfsmittel. Sie sind das Skelett, nicht die Seele des Systems. Ich habe Projekte gesehen, die alle diese Muster perfekt angewendet haben und trotzdem kläglich gescheitert sind. Warum? Weil sie die Muster isoliert betrachtet haben. Sie haben Entities gebaut, weil das im Buch steht, aber sie haben nie die Ubiquitous Language etabliert. Sie haben technisch sauberen Code geschrieben, der an der fachlichen Realität vorbeiging.
Es ist nun mal so, dass wir in der IT-Industrie dazu neigen, komplexe Ideen zu Buzzwords zu degradieren. Wir nehmen uns die Teile heraus, die einfach zu implementieren sind, und ignorieren den harten Kern. Es ist einfach, eine Klasse AggregateRoot zu nennen. Es ist verdammt schwer, mit einem uneinsichtigen Abteilungsleiter darüber zu verhandeln, warum sein Verständnis von einem Prozess logisch lückenhaft ist. Aber genau dort findet die echte Arbeit statt. Ein Architekt, der nicht kommunizieren kann, ist kein Architekt. Er ist ein technischer Zeichner.
Das Ende der Allwissenheit
Ein zentraler Aspekt, den wir oft übersehen, ist die Demut. Wir müssen akzeptieren, dass wir am Anfang eines Projekts am wenigsten über das Problem wissen. Dennoch treffen wir dort die weitreichendsten Entscheidungen. Ein guter Ansatz erlaubt es uns, dazuzulernen. Das Modell muss atmen. Es muss sich verändern dürfen, wenn wir feststellen, dass unsere ursprünglichen Annahmen falsch waren. Das ist der Punkt, an dem viele deutsche Unternehmen scheitern. Die Planungsgläubigkeit ist hierzulande oft so stark ausgeprägt, dass Abweichungen vom ursprünglichen Plan als Versagen gewertet werden. Dabei ist die Anpassung des Modells an neue Erkenntnisse der höchste Ausdruck von Professionalität.
Der kulturelle Widerstand in Organisationen
Oft liegt das Problem gar nicht in der Entwicklungsabteilung. Es liegt in der Struktur des Unternehmens. Abteilungen sind Silos. Wissen wird gehortet. Wenn die IT-Abteilung nur als Dienstleister gesehen wird, der Befehle ausführt, kann kein echtes domänengetriebenes Design entstehen. Es braucht den direkten Austausch. Es braucht die Bereitschaft des Fachbereichs, Zeit in die gemeinsame Modellierung zu investieren. In vielen Firmen wird das als Zeitverschwendung angesehen. Die Experten sollen arbeiten, nicht mit Informatikern über Begriffe reden. Diese Trennung ist der Geburtsfehler moderner Unternehmenssoftware. Wir müssen begreifen, dass Softwareentwicklung heute die Kernkompetenz fast jeder Branche ist. Wer seine Software nicht versteht, versteht sein eigenes Geschäft nicht mehr.
Die Wahrheit über die technische Umsetzung
Wenn wir die Ebene der Philosophie verlassen und uns die Implementierung ansehen, wird es oft paradox. Viele Entwickler denken, dass sie mehr Code schreiben müssen, um diesen Ansatz zu verfolgen. Das Gegenteil ist der Fall. Ein präzises Modell führt oft zu deutlich weniger, aber aussagekräftigerem Code. Wir ersetzen komplexe If-Else-Wüsten durch klare, fachliche Konzepte. Wir nutzen Value Objects, um sicherzustellen, dass eine Postleitzahl niemals nur ein String ist, sondern ein Objekt mit eigenen Validierungsregeln. Das macht den Code nicht nur sicherer, sondern auch lesbarer für Menschen, die keine Programmierer sind.
Es geht darum, die Logik dort zu konzentrieren, wo sie hingehört. In vielen traditionellen Systemen ist die Fachlogik wie Schrot über das gesamte System verteilt: in der Datenbank, in den Controllern, in der Benutzeroberfläche. Das Ergebnis ist ein unentwirrbares Geflecht aus Abhängigkeiten. Wenn wir uns konsequent an die fachlichen Grenzen halten, isolieren wir die Komplexität. Ein Fehler in der Preisberechnung wirkt sich dann nicht auf den Versand aus, weil beide in sauber getrennten Kontexten leben. Das ist keine Raketenwissenschaft, aber es erfordert Disziplin, die wir im hektischen Projektalltag oft vermissen lassen.
Die Falle der technischen Werkzeuge
Ich warne davor, sich zu sehr auf Tools zu verlassen. Es gibt keine Software, die einem das Modellieren abnimmt. Kein Diagramm-Tool der Welt kann ein schlechtes Gespräch ersetzen. Wir verbringen zu viel Zeit mit der Auswahl von Datenbanken oder Messaging-Systemen und zu wenig Zeit mit der Auswahl der richtigen Worte. Ein gut modellierter Kern ist unabhängig von der Infrastruktur. Er sollte theoretisch in einer einfachen Konsolenanwendung funktionieren können. Wenn dein Domänenmodell nur funktioniert, wenn die Datenbankverbindung steht oder ein bestimmtes Framework geladen ist, dann hast du kein Domänenmodell gebaut. Du hast eine Datenbankabstraktion gebaut. Und das ist ein himmelweiter Unterschied.
Die Rolle des Experten
Ein echter Fachexperte ist Gold wert. Aber man muss ihn auch finden und richtig nutzen. Ein Experte ist nicht unbedingt der Manager mit dem höchsten Titel. Es ist oft die Person, die seit zwanzig Jahren die Reklamationen bearbeitet und jedes Detail der Prozesse kennt. Diese Menschen haben oft das tiefste Verständnis für die verborgenen Regeln der Domäne. Sie zu ignorieren, ist der sicherste Weg in die Katastrophe. Die besten Architekten, die ich kenne, verbringen mehr Zeit damit, diesen Menschen zuzuhören, als selbst zu reden. Sie stellen Fragen wie: Was passiert, wenn dieser Fall eintritt? Warum nennen Sie das so? Gibt es eine Ausnahme von dieser Regel? Diese Fragen bohren Löcher in die Fassade der scheinbaren Klarheit, bis der wahre Kern des Problems zum Vorschein kommt.
Wir müssen aufhören, Software als ein mechanisches Konstrukt zu sehen, das man einfach zusammenbauen kann. Es ist ein lebendiges Abbild menschlichen Wissens und menschlicher Prozesse. Wenn wir dieses Wissen nicht wertschätzen, wird unser Code immer nur eine blasse und fehleranfällige Kopie der Realität bleiben. Die wirkliche Herausforderung liegt nicht darin, Code zu schreiben, den ein Computer versteht. Die Herausforderung ist es, Code zu schreiben, den ein Mensch versteht, der das fachliche Problem lösen will.
Softwarearchitektur ist am Ende des Tages angewandte Linguistik, bei der wir die Grammatik unseres Geschäftsmodells so lange verfeinern, bis der Code keine Ausrede mehr für unser mangelndes Verständnis ist.
