Einführung

Domain-Driven Design — Einführung

0:00 Domain-Driven Design hat einen zweifelhaften Ruf, und zwar aus einem nachvollziehbaren Grund: Es wird viel zu oft eingesetzt, wo es nichts zu holen gibt. Wer eine Adressverwaltung mit Entities, Aggregaten und Repositories überzieht, hat am Ende dreimal so viel Code für dasselbe Formular. Deshalb fängt dieses Modul nicht bei den Bausteinen an, sondern bei der Frage, wann sich der Aufwand überhaupt rechnet.

0:22 Danach schauen wir uns an, welche Entscheidungen im Großen fallen, wie die Zusammenarbeit mit dem Fachbereich aussieht und warum ein Domänenkern, der nichts von Datenbanken weiß, so angenehm zu testen ist. Am Ende steht die Domäne, die uns durch das ganze Seminar begleitet.

Grundlagen & Problemdomäne

0:38 Der erste Tag legt den Maßstab fest. Wir modellieren hier noch wenig — wir klären, wogegen DDD hilft und wogegen ausdrücklich nicht. Das klingt nach einer Fleißaufgabe, ist aber die wichtigste Weiche des ganzen Seminars: Wer diesen Ansatz auf das falsche Projekt wirft, produziert Aufwand ohne Ertrag und wird dem Ansatz später zu Recht misstrauen.

0:59 Sprache, Grenzen, Kerndomäne, Zusammenarbeit und die isolierte Architektur — das sind die fünf Bausteine dieses Tages. Ab Modul 2 wird dann tatsächlich Code entstehen. Ein Wort zu dem, was Sie mitbringen sollten. Objektorientierung muss sitzen, denn DDD lebt von Objekten, die Verhalten tragen statt nur Daten. Unit Tests sollten Ihnen vertraut sein, weil wir den Domänenkern durchgehend testgetrieben entwickeln.

1:24 Und ein relationaler Mapper sollte kein Fremdwort sein, weil wir später genau dort die Reibung zwischen Fachmodell und Datenbank aushalten müssen. Die Codebeispiele stehen in TypeScript — das ist eine reine Lesbarkeitsentscheidung. Kein einziges Muster dieses Seminars hängt an einer Sprache oder an einem Framework; Sie können alles genauso in Java, C# oder Kotlin bauen.

Wann DDD sich lohnt

1:46 Fangen wir mit der unbequemsten Frage an: Lohnt sich das hier überhaupt? Es gibt eine erstaunlich präzise Antwort darauf, und sie hat nichts mit Projektgröße, Teamstärke oder Budget zu tun. Sie hat mit genau einer Eigenschaft Ihres Projekts zu tun. Und weil die Antwort so klar ausfällt, lässt sie sich für jedes Projekt tatsächlich entscheiden — begründet, nicht nach Gefühl.

2:08 Genau deshalb steht diese Frage am Anfang und nicht am Ende. Domain-Driven Design ist ein Entwurfsansatz für Software mit komplexer Fachlogik. Die Betonung liegt auf fachlich. Stellen Sie sich einen Steuerberater vor: Sein Wissen steckt nicht in schnellen Rechenwegen, sondern in hunderten Regeln, Ausnahmen und Sonderfällen, die ineinandergreifen.

2:29 Genau solche Regeln bündelt DDD an einem Ort — in einem eigenen Modell, das nichts anderes tut, als das Fachgebiet abzubilden. Alles Technische wird davon ferngehalten: Datenbanken, Oberflächen, Schnittstellen. Der Gewinn ist nicht Eleganz, sondern Änderbarkeit. Wenn die Fachregel sich ändert, wissen Sie, an welcher Stelle Sie suchen müssen.

2:50 Diese Tabelle ist im Grunde ein Filter. Jedes Softwareprojekt hat eine dominierende Schwierigkeit, und die vier hier aufgeführten decken das meiste ab. Bei Sensorströmen ist es die schiere Datenmenge, bei einer Handelsplattform die Latenz, bei eingebetteter Steuersoftware die Technik selbst. Alle drei sind harte Probleme — aber DDD löst keines davon. Nur die dritte Zeile ist sein Feld: das ERP-System, in dem sich Unternehmensprozesse mit all ihren Ausnahmen stapeln.

3:17 Der Wert der Tabelle liegt in der Ehrlichkeit: Wenn Ihr Projekt nicht in diese Zeile fällt, brauchen Sie andere Mittel, und das ist kein Makel. Warum lohnt sich der Aufwand dort, wo er hingehört? Weil unbeherrschte Fachlogik eine schleichende Krankheit ist. Sie wächst über Jahre, verteilt sich über Controller, Services und Datenbank-Trigger, und irgendwann traut sich niemand mehr, etwas zu ändern, weil keiner mehr überblickt, was daran hängt.

3:43 Studien nennen genau das seit Jahrzehnten als einen der häufigsten Gründe für gescheiterte Projekte. YAGNI und KISS helfen dagegen nur begrenzt — sie begrenzen den Umfang, ordnen aber nicht, was übrig bleibt. Das leistet DDD, und zwar mit einem angenehmen Nebeneffekt: Der Code spricht am Ende die Sprache des Fachbereichs, statt sie zu verstecken.

4:03 Diese vier Fehler sehen Sie in der Praxis ständig, und sie haben alle dieselbe Wurzel: DDD wird als Qualitätsmerkmal verstanden statt als Werkzeug für ein bestimmtes Problem. Eine CRUD-Maske mit Aggregaten zu überziehen, macht sie nicht besser, nur teurer. Gegen Performance-Probleme wirkt es schlicht nicht; da hilft Profiling.

4:22 Besonders verbreitet ist der dritte Punkt: Man übernimmt die taktischen Muster — Entity, Value Object, Repository — weil sie konkret und greifbar sind, bevor überhaupt jemand die Fachlogik durchdrungen hat. Dann entstehen Klassen mit den richtigen Namen und den falschen Regeln. Und vorsorgliches Modellieren rächt sich fast immer.

Die strategischen Bausteine

4:41 Wenn DDD passt, stellt sich als Nächstes die Frage nach der Reihenfolge. Und die ist eindeutig: Das Große kommt vor dem Kleinen. Drei Muster entscheiden über Erfolg oder Misserfolg, lange bevor die erste Klasse geschrieben ist. Wer hier die Reihenfolge umdreht und mit den handfesten Bausteinen beginnt, baut sauberen Code an der falschen Stelle.

5:01 Diese drei Muster kosten kaum Aufwand und entscheiden trotzdem am meisten. Die strategischen Muster ordnen das Große. Denken Sie an den Bau eines Stadtviertels: Bevor über Fenstergriffe gesprochen wird, muss feststehen, wo die Straßen verlaufen, wo Wohnen aufhört und Gewerbe anfängt, und welches Gebäude das Herzstück ist.

5:20 Genau das leisten die drei Muster — eine gemeinsame Sprache, klare Grenzen zwischen Teilsystemen und die Entscheidung, welcher Teil die eigentliche Wertschöpfung trägt. Entities und Repositories, die in vielen Vorträgen im Mittelpunkt stehen, sind dagegen nur die Taktik. Sie sind wichtig, aber sie retten keinen Entwurf, dessen Grenzen falsch gezogen sind.

5:41 Der Trick bei dieser Tabelle liegt in der rechten Spalte. Muster merkt man sich schlecht, Fragen dagegen gut — und jedes dieser drei Muster ist im Kern die Antwort auf eine Frage, die man im Projekt tatsächlich stellt. Wie nennen wir dasselbe Ding? Wo hört ein Modell auf zu gelten? Und: Wo lohnt sich unsere Sorgfalt am meisten? Die dritte ist die unbequemste, weil sie eine Absage enthält.

6:04 Nicht jede Fachlogik ist Kerndomäne. Buchhaltung ist komplex, aber sie unterscheidet Ihr Unternehmen von keinem anderen — sowas kauft man zu, statt es liebevoll selbst zu modellieren. Diese Folie beschreibt ein Phänomen, das Sie garantiert schon erlebt haben. Der Fachbereich sagt „Aufladen", die Entwicklung schreibt „Gutschrift", und beide sind überzeugt, dasselbe zu meinen.

6:27 Meistens stimmt das sogar — bis zu dem Tag, an dem es nicht mehr stimmt und niemand merkt, wo die Bedeutung auseinandergelaufen ist. Deshalb ist die Regel so schlicht wie unbequem: Einer muss weichen. Es gibt ein Wort, und das steht in der Klasse, in der Tabelle, im Fachkonzept und im Meeting. Und wenn Ihnen im Gespräch eine Abweichung auffällt, sprechen Sie sie an — nicht still im Kopf übersetzen.

6:51 Diese Aufgabe ist bewusst keine Programmieraufgabe. Sie sollen üben, Widersprüche in der Sprache eines Teams zu erkennen und zu einer verbindlichen Benennung zu führen — das ist eine Gesprächsfähigkeit, keine Tippfähigkeit. Nehmen Sie Begriffe aus Ihrem eigenen Projekt, nicht aus dem Waschsalon; der Erkenntniswert liegt genau darin, dass es wehtut.

7:11 Erfolgreich sind Sie, wenn für drei strittige Begriffe je ein Wort feststeht, auf das sich Fachbereich und Code ab sofort festlegen. Und Sie werden merken: Der schwierige Teil ist nicht die Auswahl, sondern das Loslassen des eigenen Lieblingsworts.

Arbeit mit Fachexperten

7:25 Eine gemeinsame Sprache entsteht nicht am Schreibtisch. Sie entsteht im Gespräch, und zwar in einem, das nicht einmal zu Projektbeginn stattfindet, sondern durchgehend. Wie diese Zusammenarbeit praktisch aussieht, klären wir jetzt. Und das ist kein weicher Nebenschauplatz, sondern die Arbeit, aus der das Modell überhaupt erst entsteht.

7:45 Wer sie überspringt, modelliert die eigene Vermutung statt der Domäne. Hier steckt der Punkt, an dem DDD sich am deutlichsten von anderen Ansätzen unterscheidet: Es ist nicht nur eine Art zu programmieren. Es setzt einen laufenden Austausch mit Fachexperten voraus — und zwar in beide Richtungen. Das wird oft überlesen. Die eine Richtung ist selbstverständlich: Der Fachbereich erklärt die Domäne. Die andere ist die interessante: Sie melden zurück, welche Widersprüche das Modell sichtbar macht.

8:14 Modellieren ist nämlich eine Form von sehr genauem Nachfragen. Wenn eine Regel sich nicht sauber abbilden lässt, liegt das erstaunlich oft nicht am Code, sondern an einer Unschärfe im Fachgebiet selbst. Diese fünf Schritte laufen nicht nacheinander ab, sondern beschreiben eine Arbeitshaltung. Der erste ist der härteste: direkter Zugang zu Fachexperten, nicht über Dritte.

8:36 Jede Zwischenstation kostet Bedeutung, und ein Anforderungsdokument ist bereits eine Zwischenstation. Der zweite Schritt sagt, dass Domänenwissen kein Projektabschnitt ist, sondern eine Dauerleistung. Schritt drei und vier gehören zusammen: Unstimmigkeiten sofort ansprechen und Randfälle aus dem Code zurückspiegeln — das sind die Momente, in denen Sie dem Fachbereich tatsächlich etwas geben.

8:59 Und Schritt fünf ist die Reihenfolgeentscheidung: Die Kerndomäne wird zuerst modelliert, ohne Oberfläche, ohne Datenbank. Warum sollte man sich diese Mühe machen, wenn es doch so viel Technik zu bauen gibt? Genau darin liegt die Falle, die der zweite Punkt beschreibt. Infrastrukturarbeit fühlt sich produktiv an — sie hat sichtbare Ergebnisse, klare Erfolgskriterien und lässt sich abends gut erzählen. Nur trägt sie das Projekt nicht.

9:24 Ohne die Fachsicht entsteht technisch sauberer, fachlich falscher Code, und das ist die teuerste Sorte von Fehler. Wer die Domäne dagegen wirklich durchdringt, findet regelmäßig Vereinfachungen, nach denen niemand gefragt hat. Und diese Fähigkeit bleibt Ihnen: Modellieren können ist übertragbar, auch wenn Sie die Branche wechseln.

Onion-Architektur und Isolation

9:44 Bleibt die Frage, wie man ein Domänenmodell technisch sauber hält. Denn ein Modell, das die halbe Infrastruktur kennt, ist kein Modell mehr, sondern eine Schicht. Die Antwort ist eine Anordnung in Ringen — mit einer einzigen, sehr konsequenten Regel. Diese Regel klingt streng und ist der Grund dafür, dass sich der Kern in Millisekunden testen lässt — was uns direkt zum nächsten Kapitel führt.

10:08 Die Onion-Architektur legt die Bausteine in Ringe, wie bei einer Zwiebel. Außen liegt die Oberfläche, innen das Domänenmodell. Und dann kommt die eine Regel, auf der alles ruht: Abhängigkeiten zeigen ausschließlich nach innen. Der innerste Ring hängt von nichts ab außer von sich selbst. Das klingt nach einer Formalie, hat aber eine sehr handfeste Konsequenz: Sie können den Kern kompilieren, testen und verstehen, ohne dass irgendwo eine Datenbank läuft.

10:34 Man merkt das im Alltag daran, wie schnell die Tests durchlaufen — und wie wenig Aufwand nötig ist, um eine Fachregel zu prüfen. Lesen Sie die Tabelle von unten nach oben, dann sehen Sie die Logik. Ganz innen stehen die Bausteine, die reine Fachlichkeit tragen. Ein Ring weiter liegt alles, was zwischen Fachlichkeit und Außenwelt vermittelt: Repositories holen und speichern, Factories erzeugen, Domain Services tragen Regeln, die zu keiner einzelnen Entity gehören.

11:01 Darüber die Anwendungsservices, die Abläufe orchestrieren und Transaktionsgrenzen ziehen — sie koordinieren, sie entscheiden nicht fachlich. Und außen die Oberfläche. Auffällig ist, was fehlt: die Datenbank. Sie taucht in keinem Ring auf, weil sie hinter den Repositories steckt und den Kern nichts angeht. Worauf es bei diesem Beispiel ankommt, ist nicht, was dasteht, sondern was fehlt. Sie sehen eine Guthabenkarte mit einem Saldo und einer Methode, die sie belastet.

11:30 Die Fachregel steckt genau dort, wo sie hingehört: Reicht das Guthaben nicht, scheitert der Vorgang, und der Saldo bleibt unangetastet. Jetzt schauen Sie auf das, was nicht im Code steht. Kein Import aus einer äußeren Schicht, kein Speicheraufruf, kein Tabellenname, keine Annotation eines Frameworks. Diese Klasse weiß nicht einmal, dass es eine Datenbank gibt. Genau deshalb lässt sie sich in Millisekunden testen — und genau deshalb überlebt sie den nächsten Technologiewechsel.

11:59 Die Isolation des Kerns bröckelt selten mit einem Knall, sondern in kleinen Zugeständnissen. Es fängt harmlos an: ein Tabellenname als Konstante, weil es gerade praktisch ist. Der zweite Punkt ist die Umkehr der Abhängigkeit — der Kern ruft selbst ein Repository auf und ist damit an die Außenwelt gebunden. Der dritte ist der heimtückischste, weil er sich richtig anfühlt: Die Fachlogik wandert nach und nach in die Anwendungsservices, und der Kern bleibt als leere Datenhülle zurück.

12:28 Das ist dann ein anämisches Modell mit DDD- Vokabular. Und der parameterlose Konstruktor fürs ORM ist selten das Problem — er wird nur gern als Präzedenzfall für alles Weitere zitiert.

Unit Tests im Domänenmodell

12:39 Ein isolierter Kern hat eine sehr praktische Nebenwirkung: Er ist trivial zu testen. Das führt zur nächsten Frage, bei der in Projekten viel Geld verbrannt wird — nämlich, wo Testabdeckung sich eigentlich rechnet. Die Antwort darauf ist keine Zahl fürs ganze Projekt, sondern eine Aufteilung. Und sie erklärt nebenbei, warum Abdeckungskennzahlen so oft in die Irre führen.

13:02 Testabdeckung ist kein Selbstzweck, und diese Folie sagt auch, warum. Der Nutzen weiterer Unit Tests fällt ab, je näher Sie an hundert Prozent kommen — die letzten Prozente sind meistens Getter, Konstruktoren und Fehlerpfade, die nie eintreten. Der Aufwand dagegen wächst linear weiter. Daraus folgt eine Aufteilung statt einer Zahl fürs ganze Projekt: Der Kern verdient die volle Abdeckung, weil dort das Fachwissen steckt und die Tests fast nichts kosten.

13:28 Die äußeren Ringe verdienen Integrationstests, weil dort die Frage interessanter ist, ob das Zusammenspiel funktioniert. Vier Gründe, und der wirtschaftlichste ist der dritte. Im Kern liegt der Aufwand je Test extrem niedrig, weil keine Infrastruktur hochfahren muss — kein Container, keine Testdatenbank, kein Warten. Sie schreiben einen Test in einer Minute und bekommen die Antwort in Millisekunden.

13:52 Gleichzeitig ist der Ertrag am höchsten, weil dort das meiste Fachwissen steckt und Fehler am teuersten sind. Dazu kommt ein Effekt, den man leicht unterschätzt: Diese Tests halten die Fachregeln nebenbei nachlesbar fest. Für einen neuen Kollegen ist die Testklasse oft die bessere Dokumentation als jedes Fachkonzept. Dieser Test ist absichtlich unspektakulär, und das ist die Botschaft.

14:15 Eine Karte mit zwei Euro fünfzig, ein Versuch, drei Euro zu belasten, und zwei Erwartungen: Der Vorgang scheitert, und der Saldo hat sich nicht verändert. Die zweite Erwartung ist die wichtigere — sie prüft, dass der Fehlerfall keine halben Zustände hinterlässt. Achten Sie auf die Form: Aufbau, Ausführung, Prüfung, getrennt durch Leerzeilen statt durch Kommentare.

14:37 Und achten Sie auf das, was auch hier fehlt: kein Mock, keine Datenbank, kein Testrahmen mit Konfiguration. Der Test liest sich wie ein Satz in Fachsprache, und genau so sollte er sich lesen. Beim Testen sind die typischen Fehler eher wirtschaftlicher als technischer Natur. Hundert Prozent über die ganze Codebasis anzustreben, klingt vorbildlich und ist meistens Verschwendung.

15:00 Der zweite Punkt ist dagegen ein guter Sensor: Wenn ein Unit Test eine Datenbank braucht, sagt Ihnen das nichts über den Test, sondern etwas über Ihren Kern — er ist nicht isoliert. Ähnlich der dritte: Wer äußere Ringe mit Mock-Bergen unit-testet, testet am Ende sein Mocking-Framework. Und die vierte Falle ist die berichtete Kennzahl.

15:19 Achtzig Prozent Abdeckung bedeuten gar nichts, solange niemand sagt, welche achtzig Prozent.

Die Beispieldomäne Waschsalon Perlbach

15:25 So viel zur Theorie. Ab jetzt brauchen wir etwas Konkretes, an dem sich all das zeigen lässt — eine Domäne, die klein genug ist, um sie zu überblicken, und komplex genug, dass DDD sich lohnt. Lernen Sie den Waschsalon Perlbach kennen. Sie begleitet uns durch alle acht Module, und das ist Absicht: Nur an einer durchgehenden Domäne lässt sich zeigen, wie die Muster zusammenwirken.

15:48 Alle Module dieses Seminars arbeiten an einer einzigen Domäne, und das ist eine bewusste Entscheidung. Wechselnde Spielzeugbeispiele erklären einzelne Muster gut, aber sie zeigen nie, wie die Muster zusammenwirken — und genau darum geht es. Der Waschsalon Perlbach funktioniert wie viele, die Sie kennen: Ein Kartenautomat nimmt Bargeld an und lädt Guthaben auf eine Karte, die Waschautomaten belasten dieses Guthaben, und die Filialverwaltung führt Buch über alles.

16:14 Klingt einfach. Sie werden überrascht sein, wie viele Fachregeln, Randfälle und Grenzentscheidungen in diesem harmlosen Gerät stecken. Achten Sie darauf, wie diese Tabelle formuliert ist: ausschließlich in Fachsprache. Geld annehmen, Guthaben aufladen, Rückgeld auszahlen. Programm wählen, Karte belasten, Lauf freigeben. Kein Wort über Schnittstellen, Datenbanken oder Services — und trotzdem versteht jeder sofort, was das System tut.

16:41 Genau so sollte eine Domäne anfangen. Wichtig ist die Fußzeile: Aus Kartenautomat und Waschautomat werden zwei eigene Bounded Contexts, in Modul 2 und Modul 6. Beide sprechen von einer Karte, aber sie meinen Unterschiedliches — und das auszuhalten, statt eine gemeinsame Superklasse zu bauen, ist eine der zentralen Lektionen dieses Seminars.

17:03 Diese Reihenfolge ist die Onion-Architektur in Handlungsform. Wir fangen ganz innen an, bei Geldbeträgen als Value Object — und zwar mit einzeln gezählten Münzen und Scheinen, denn ein Automat, der Rückgeld auszahlen muss, kann mit einer bloßen Summe nichts anfangen. Dann kommt der Kartenautomat als Entity mit seinen Regeln. Erst danach die Tests, die diese Regeln absichern, und ganz zuletzt die Persistenz.

17:27 Widerstehen Sie dem Reflex, mit dem Datenbankschema anzufangen. Der Automat kennt übrigens sechs Werte von zehn Cent bis zehn Euro — mehr braucht das Modell nicht, und mehr modellieren wir auch nicht. Jetzt sind Sie dran, und zwar noch ohne Editor. Aus einer Gerätebeschreibung sollen Sie die Regeln herauslösen, die ein Domänenmodell abbilden muss — mindestens fünf, als Sätze in Fachsprache, ohne Klassen, ohne Tabellen, ohne Technik.

17:53 Das ist schwerer, als es klingt, weil die Finger sofort in Richtung Datenmodell zucken. Ein Tipp, der fast immer trägt: Fangen Sie bei den Randfällen an. Leeres Guthaben, zu wenig Rückgeld im Automaten, ein Vorgang, den jemand mittendrin abbricht. Dort sitzt die eigentliche Fachlogik — der Normalfall ist meistens trivial.

Was du mitnimmst

18:13 Vier Dinge aus diesem Modul. Erstens: DDD rechnet sich nur bei komplexer Fachlogik, alles andere ist Aufwand ohne Ertrag — und diese Ehrlichkeit macht den Ansatz erst glaubwürdig. Zweitens: Strategisch vor taktisch. Gemeinsame Sprache, Bounded Context, Kerndomäne fallen, bevor die erste Klasse entsteht. Drittens: Der Kern bleibt frei von Persistenz, und genau daraus folgt seine gute Testbarkeit — das ist kein Zufall, sondern derselbe Sachverhalt aus zwei Blickwinkeln.

18:43 Ab Modul 2 wird modelliert: Value Object, Entity und der erste Automat des Waschsalons.