Wendet man DDD auf DDD an, bleibt kein Domain-Driven Design übrig

Domain-Driven Design (DDD) verspricht bessere Software durch Fokus auf die Fachdomäne und ein gemeinsames Verständnis zwischen Developern und Fachleuten. Das ist die Essenz, verdichtet auf einen Satz. Aber wenn Sie dieses Prinzip tatsächlich auf DDD selbst anwenden (also fragen, was die Domäne ist, was wichtig ist, was man weglassen kann, …), dann landen Sie nicht bei dem, was wir heute „DDD“ nennen. Sie landen bei etwas viel Einfacherem.

Warum also hat DDD nach mehr als zwei Jahrzehnten nie seine Nische verlassen? Warum fühlen sich so viele Entwicklerinnen und Entwickler davon überfordert, verwirrt, oder glauben, sie seien nicht schlau genug dafür? Die Antwort ist unbequem, aber klar: DDD scheitert an seinem eigenen Anspruch.

Das Problem: DDD schreckt Menschen ab

DDD gibt es seit 2003. Das Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans gilt als Klassiker, und die darin enthaltenen Ideen sind mächtig. Trotzdem bleibt DDD auf eine relativ kleine Gemeinschaft beschränkt. Es ist nicht Mainstream geworden. Es hat nicht revolutioniert, wie die meisten Teams Software bauen. Und ein wesentlicher Grund dafür ist: Wir verlieren die Leute, bevor sie überhaupt die Kernidee verstanden haben.

Statt Entwicklerinnen und Entwickler dort abzuholen, wo sie stehen, erschlagen wir sie mit einer Unmenge an Theorie: Aggregates, Bounded-Contexts, Value Objects, Entities, Repositories, Anti-Corruption Layers, Ubiquitous Language, Strategic Design, Tactical Design und so weiter. Allein die Terminologie ist einschüchternd. Die Konzepte sind abstrakt. Die Beispiele bleiben oft akademisch. Und wenn jemand sich durch all das durchgearbeitet hat, ist er entweder erschöpft oder überzeugt davon, dass DDD nur etwas für Enterprise-Architektinnen und -Architekten mit jahrzehntelanger Erfahrung ist.

Das ist kein Zufall. DDD wurde akademisiert. Es wurde zu einem Framework gemacht, einer Methodik, einem Zertifizierungspfad. Es wurde in Jargon gehüllt und unter Schichten von Pattern-Katalogen begraben. Was als einfache, menschenzentrierte Idee begann („verstehe die Domäne und sprich die Sprache des Business“) ist zu etwas geworden, das sich für die meisten unerreichbar anfühlt.

Und das ist das Paradox: DDD soll Softwareentwicklung erleichtern und besser an der Realität ausrichten. Aber die Art, wie wir es lehren, wie wir darüber sprechen, wie wir es praktizieren: All das macht es schwieriger.

Intention vs. Implementierung: Eine bekannte Geschichte

Das ist kein neues Problem. Dasselbe ist mit den Design-Pattern der „Gang of Four“ passiert.

Nehmen Sie beispielsweise das Singleton-Pattern. Die Intention ist einfach: Man will sicherstellen, dass eine Klasse genau eine Instanz hat. Das ist alles. Das ist das Problem, das das Pattern löst. Aber was haben die meisten Entwicklerinnen und Entwickler gelernt? Die Implementierung: einen privaten Konstruktor und eine statische getInstance()-Methode. Sie haben den Code auswendig gelernt. Sie haben ihn mechanisch angewendet. Und (zu) viele von ihnen haben nie verstanden, dass die Implementierung nur ein Weg ist, die Intention zu erreichen. Die Implementierung wurde zum Pattern selbst.

Dasselbe ist mit DDD passiert. Die Intention ist klar: Man will bessere Software bauen, indem man sich auf die Fachdomäne konzentriert und eine gemeinsame Sprache mit Fachleuten entwickelt. Aber was lernen Entwicklerinnen und Entwickler? Sie lernen die Implementierung: eine lange Liste von Pattern und (technischen) Konzepten. Und genau wie beim Singleton glauben viele, dass das Anwenden dieser Pattern DDD ist. Sie behandeln es wie eine Checkliste.

„Haben wir Aggregates? Check. Haben wir Value Objects? Check. Haben wir Bounded Contexts? Check.“

Aber das ist nicht DDD. Das ist Pattern-Theater. Es ist Form ohne Substanz. Es ist wie Daily Stand-ups, Sprints und Retrospektiven abzuhalten und sich agil zu nennen, obwohl sich an der Kultur, Kommunikation oder Entscheidungsfindung des Teams nichts geändert hat. Man führt die Rituale durch, aber man verfehlt den Punkt.

Die große Flucht: Sich hinter Pattern verstecken

Hier ist die unbequeme Wahrheit: DDD ist im Kern nicht technisch. Was es wirklich von Ihnen verlangt, ist Folgendes: Verlassen Sie Ihre Komfortzone. Sprechen Sie mit Fachexpertinnen und Fachexperten. Nicht nur, um Anforderungen zu sammeln, sondern um ihre Welt wirklich zu verstehen. Hören Sie zu. Stellen Sie Fragen. Halten Sie Unsicherheit aus. Geben Sie zu, wenn Sie etwas nicht verstehen. Entwickeln Sie eine gemeinsame Sprache, iterativ und kollaborativ – und damit vor allem auch ein gemeinsames Verständnis.

Das ist harte Arbeit. Es ist Arbeit mit Menschen. Es ist unbequeme Arbeit. Sie erfordert Demut, Geduld und Kommunikationsfähigkeiten, in denen viele Entwicklerinnen und Entwickler, mich eingeschlossen, nicht ausgebildet wurden. Es ist viel einfacher, im technischen Bereich zu bleiben, wo Dinge vorhersagbar und kontrollierbar sind.

Und hier ist die Falle: Die Pattern bieten Ihnen ein perfektes Versteck.

Statt mit Menschen zu reden, können Sie darüber diskutieren, ob etwas ein Aggregate oder eine Entity sein sollte. Statt die Domäne zu verstehen, können Sie Bounded-Context-Diagramme zeichnen. Statt Fachexpertinnen und Fachexperten zu fragen „Wie nennt ihr das?“, können Sie Ihre Kolleginnen und Kollegen fragen „Ist das ein Value Object?“. Sie fühlen sich produktiv. Sie schaffen Struktur, zeichnen Diagramme, wenden Pattern an. Aber die eigentliche Arbeit, die harte, menschliche, domänenfokussierte Arbeit, wird beiseitegeschoben.

Deshalb sehen so viele DDD-Projekte technisch ausgereift aus, fühlen sich aber vom Business abgekoppelt an. Der Code ist voll von den richtigen Pattern, aber er spricht nicht die Sprache der Domäne. Die Architektur ist sauber, aber die Entwicklerinnen und Entwickler verstehen immer noch nicht wirklich, was die Software tun soll oder warum.

„Ich bin zu dumm für DDD“

Leider hat das einen sehr traurigen, oft persönlichen Grund. Denn das Gefühl, das die Beschäftigung mit DDD bei vielen hinterlässt, ist Unsicherheit. Ich selbst dachte jahrelang, ich sei zu dumm für DDD, weil ich nicht das Gefühl hatte, es wirklich verstanden zu haben. Natürlich habe ich das Blue Book gelesen. Ich habe mir Vorträge angeschaut. Und das große Ganze ergab durchaus Sinn: Fokussiere dich auf die Domäne, baue ein gemeinsames Verständnis auf! Aber bei den Details verlor ich mich. Aggregates, Bounded Contexts, Anti-Corruption Layers. Ich verstand sie in der Theorie, aber ich fühlte mich nie sicher, sie anzuwenden. Ich dachte, alle anderen „kapieren“ es einfach, und ich nicht.

Dann wurde mir klar: Das Problem war nicht ich. Das Problem war die Art, wie DDD gelehrt wird.

DDD wurde unnötig verkompliziert. Es wurde in akademische Sprache gekleidet, unter Abstraktionsschichten begraben und so präsentiert, als bräuchte man einen Doktor in Softwarearchitektur, um es zu verstehen. Aber das ist nicht, was DDD ist. DDD ist nicht kompliziert. Wir haben es kompliziert gemacht.

Wenn Sie sich jemals genauso gefühlt haben, wenn Sie jemals dachten, Sie seien nicht schlau genug für DDD, oder dass es nur für bestimmte Arten von Projekten sei, oder dass es einfach zu abstrakt sei, um nützlich zu sein, dann kann ich Ihnen versichern: Sie sind nicht allein. Und Sie sind nicht das Problem.

Worum es bei DDD wirklich geht

Streifen wir die Komplexität ab und kommen zur Essenz. Hier ist DDD in einem Satz:

Bauen Sie bessere Software, indem Sie die Fachdomäne verstehen und eine gemeinsame Sprache mit den Menschen sprechen, die darin arbeiten.

Das ist alles. Alles andere – all die Pattern, all die Diagramme, all die Terminologie – ist sekundär. Die Pattern sind Werkzeuge. Sie können Ihnen helfen, die Domäne klarer im Code auszudrücken. Aber sie sind nicht das Ziel. Das Ziel ist Verstehen.

Wie sieht das also in der Praxis aus?

Erstens: Reden Sie mit Menschen, nicht mit Diagrammen. Die wichtigste Frage, die Sie stellen können, ist nicht „Ist das eine Entity oder ein Value Object?“, sondern sie lautet „Wie nennt ihr das?“. Verbringen Sie Zeit mit Fachexpertinnen und Fachexperten. Hören Sie zu, wie sie ihre Arbeit beschreiben. Achten Sie auf die Wörter, die sie benutzen, die Unterscheidungen, die sie machen, die Dinge, die ihnen wichtig sind. Daher kommt die gemeinsame Sprache. Nicht aus UML-Diagrammen, sondern aus echten Gesprächen.

Zweitens: Benutzen Sie die Sprache der Domäne, nicht die Sprache der Technik. Wenn die Fachleute von Kundinnen und Kunden, Gästen und Benutzerinnen und Benutzern als drei verschiedenen Konzepten sprechen, dann sollte Ihr Code das widerspiegeln. Fassen Sie sie nicht alle in einer einzigen User-Klasse zusammen, nur weil es einfacher ist. Nennen Sie etwas nicht UserEntity, wenn das Business es Customer nennt. Die Präzision der Sprache ist wichtig. Das ist nicht pedantisch, es ist vielmehr der Kern von DDD.

Drittens: Benennen Sie Dinge exakt. Ist es „stornieren“ oder „erstatten“? Ist es eine „Rechnung“ oder ein „Beleg“? Ist es „zurückgeben“ oder „widerrufen“? Das sind keine trivialen Unterscheidungen. Sie repräsentieren verschiedene Geschäftsprozesse, verschiedene Regeln, verschiedene Bedeutungen. Wenn Sie die Namen falsch wählen, haben Sie bereits die Ausrichtung mit der Domäne verloren.

Viertens: Weg von CRUD. Create, Read, Update, Delete – das sind technische Operationen, keine Geschäftsprozesse. Sie erfassen nicht, was tatsächlich in der Domäne passiert. Denken Sie stattdessen in Verben, die aus dem Business kommen: confirmOrder(), cancelOrder(), changeDeliveryAddress(). Diese Namen sagen Ihnen, was das System tut und warum.

Schließlich: Pattern sind Werkzeuge, keine Ziele. Wenn Ihnen ein Aggregate-Pattern hilft, ein Geschäftskonzept klarer auszudrücken, benutzen Sie es. Wenn nicht, lassen Sie es weg. Lassen Sie die Domäne Ihre Struktur leiten, nicht Pattern-Kataloge. Die Pattern existieren, um der Domäne zu dienen, nicht umgekehrt.

Warum sich Event Sourcing natürlich anfühlt

Tatsächlich gibt es etwas, das mir über die Jahre aufgefallen ist, was enorm helfen kann: Menschen verstehen Events intuitiv.

Events sind, wie wir natürlich über die Welt denken. Wir erzählen Geschichten als Abfolge von Dingen, die passiert sind. Wir beschreiben unseren Tag in Events: Ich bin aufgewacht, ich habe gefrühstückt, ich bin zur Arbeit gefahren, ich war in einem Meeting. Wenn wir Geschichte erzählen, sprechen wir über Events: Die Mauer fiel, der Vertrag wurde unterzeichnet, die Entdeckung wurde gemacht. Das ist keine technische Abstraktion. Es ist, wie Menschen Informationen verarbeiten und kommunizieren.

Stellen Sie sich vor, Sie erzählen die Geschichte von Rotkäppchen. Sie würden es nicht so machen:

UPDATE Rotkäppchen SET ort = 'Wald' UPDATE Wolf SET ort = 'Wald' UPDATE Rotkäppchen SET emotion = 'verängstigt' DELETE Großmutter UPDATE Wolf SET verkleidung = 'Großmutter'

Das ist absurd. Es streift alle Bedeutung ab, alle Kausalität, alle Erzählung. Sie würden es als Abfolge von Events erzählen:

RotkäppchenBetratDenWald RotkäppchenTrafDenWolf WolfGingZumHausDerGroßmutter WolfVerschlangDieGroßmutter WolfVerkleideteSichAlsGroßmutter

So funktionieren Geschichten. So verstehen wir, was passiert ist und warum. Und genau so funktioniert Event Sourcing.

Event Sourcing fragt nicht „Was ist der aktuelle Zustand?“, sondern „Was ist passiert?“. Es speichert ein chronologisches Protokoll von Fakten und Geschehnissen in der Vergangenheit, unveränderlich und unbestreitbar. Und aus diesem Protokoll können Sie den aktuellen Zustand rekonstruieren, die Historie abspielen, Kausalität verstehen und ein vollständiges Bild davon aufbauen, was zu dem geführt hat, wo Sie jetzt sind.

Event Sourcing als leichtgewichtiger Weg zu DDD

Event Sourcing ist nicht nur eine Art, Daten zu speichern. Es ist auch ein überraschend effektiver, leichtgewichtiger Einstieg in die Welt von DDD, weil es Sie natürlich in die richtige Richtung schiebt.

Erstens zwingt es Sie, in Verben zu denken, nicht in CRUD. Events haben Namen wie OrderPlaced, PaymentReceived oder ItemShipped. Nicht createOrder, updatePayment oder deleteItem. Sie können nicht auf generische CRUD-Operationen zurückfallen. Sie müssen beschreiben, was tatsächlich im Business passiert ist. Das bringt Sie sofort näher an die Domänensprache.

Zweitens: Events nach Subjekten zu organisieren, ist die halbe Aggregate-Diskussion. Welche Events gehören zusammen? Alle Events für eine bestimmte Bestellung landen unter /orders/42. Alle Events für eine bestimmte Kundin oder einen bestimmten Kunden vielleicht unter /customers/23. Oder Sie strukturieren es anders: /customers/23/orders/42. Die Art, wie Sie Events gruppieren, spiegelt die Struktur der Domäne wider. Sie machen die Arbeit, Aggregates zu definieren, aber Sie machen es konkret, indem Sie entscheiden, welche Events zusammengehören, nicht indem Sie abstrakte Konzepte debattieren.

Drittens: Zu entscheiden, welcher Service welche Events verarbeitet, ist die Bounded-Context-Diskussion. Soll der Order-Service PaymentReceived verarbeiten, oder sollte das der Billing-Service sein? Was gehört zu Inventory versus Fulfillment? Das sind Bounded-Context-Fragen. Aber Sie zeichnen keine Diagramme. Sie treffen konkrete Entscheidungen darüber, welcher Teil Ihres Systems für welche Events verantwortlich ist. Die Domäne entsteht natürlich aus diesen Entscheidungen.

Schließlich: Events sind selbsterklärend. Sie müssen keine Aggregates, Entities oder Value Objects verstehen, um zu wissen, was CustomerRegistered bedeutet. Sie brauchen keinen Abschluss in DDD, um herauszufinden, was BookBorrowed darstellt. Events sprechen die Sprache des Business. Sie sind zugänglich. Sie sind konkret. Sie sind sofort verständlich.

Schauen wir uns ein einfaches Beispiel aus einem Bibliothekssystem an. Statt darüber nachzudenken, ob ein Buch eine Entity oder ein Aggregate ist, fragen Sie zunächst: Was kann mit einem Buch passieren?

• BookAcquired: Die Bibliothek bekommt ein neues Buch.
• BookBorrowed: Jemand leiht es aus.
• BookReturned: Es wird zurückgebracht.
• LateFeeCharged: Es wurde zu spät zurückgebracht und daher eine Strafe berechnet.
• BookRemoved: Die Bibliothek sortiert es aus.

Diese Events erzählen die Geschichte. Sie erfassen den Geschäftsprozess. Und wenn Sie sie nach Subjekt organisieren, sagen wir /books/42 für Buch Nummer 42, haben Sie gerade definiert, was in DDD-Begriffen ein Aggregate genannt würde. Sie haben die Theorie nicht gebraucht. Sie haben einfach gefragt: Was passiert, und was gehört zusammen?

Ein Plädoyer für pragmatisches DDD

Vielleicht brauchen wir nicht mehr DDD. Vielleicht brauchen wir pragmatischeres DDD.

Streifen Sie die akademische Sprache ab! Hören Sie auf, Pattern als Ziel zu behandeln! Hören Sie auf, Menschen mit Theorie zu überwältigen, bevor sie auch nur eine Zeile Code geschrieben haben! Kommen Sie zurück zur Essenz: Fokussieren Sie sich auf die Domäne, sprechen Sie die Sprache des Business, bauen Sie ein gemeinsames Verständnis auf!

Wenn Sie DDD lernen wollen, fangen Sie hier an:

• Vergessen Sie die Pattern zunächst. Lernen Sie, gute Gespräche mit Fachexpertinnen und Fachexperten zu führen.
• Lernen Sie, aufmerksam zuzuhören, die richtigen Fragen zu stellen und Unsicherheit auszuhalten.
• Lernen Sie, in Events zu denken: Was ist passiert, und warum?
• Lassen Sie die Domäne Ihren Code leiten, nicht umgekehrt.

Wenn Sie DDD bereits praktizieren, fragen Sie sich ehrlich:

• Verstecke ich mich hinter Pattern, statt die schwierige Arbeit auf mich zu nehmen, die Domäne zu verstehen?
• Wie viel Zeit verbringe ich mit Fachexpertinnen und Fachexperten im Vergleich dazu, wie viel Zeit ich mit dem Zeichnen von Diagrammen verbringe?
• Spricht mein Code die Sprache des Business, oder spricht er die Sprache der Technik?
• Benutze ich CRUD, oder benutze ich Events und Domänen-Verben?

DDD war nie dazu gedacht, kompliziert zu sein. Wir haben es kompliziert gemacht. Wenn wir DDD ernst nehmen, wenn wir seine eigenen Prinzipien auf DDD selbst anwenden, dann müssen wir zugeben: Wir sind vom Kern abgedriftet. Wir haben Abstraktionsschichten gebaut, die die darunter liegende Einfachheit verdecken.

Event Sourcing kann helfen. Es ist konkret. Es ist intuitiv. Es passt natürlich dazu, wie Menschen denken. Und es schiebt Sie, fast mühelos, zu den Praktiken, um die es bei DDD schon immer ging: verstehen, was passiert ist, es präzise benennen und die Sprache der Domäne sprechen.

Wenn Sie Event Sourcing interessiert und Sie sehen wollen, wie es Sie zu besserer Domänenmodellierung führen kann, ohne den Overhead, fangen Sie mit einer Einführung in Event Sourcing an. Vielleicht stellen Sie fest, dass der Weg zu DDD einfacher ist, als Sie dachten.

(rme)