© Nina Firsova / 123RF.com

Das Domain-driven Design adressiert viele Aspekte der Softwareentwicklung, vom Design ganzer Softwarelandschaften und den Beziehungen zwischen (Teil-)Systemen über den Entwurf fachlicher Modelle bis hin zu Mustern und Code.

Als Eric Evans 2003 sein namensgebendes Buch “Domain-driven Design – Tackling Complexity in the Heart of Software” [1] schrieb, hatte er vor allem Unternehmenssoftware im Blick: Projektteams entwickeln Software für Fachbereiche. Seitdem hat sich eine lebendige Community um das Domain-driven Design (DDD) etabliert, die den Ansatz weiterentwickelt. Dadurch ist er mittlerweile auch in der Entwicklung von anderen Softwareprodukten verbreitet.

Fachliche Modelle

Um Software zu bauen, die fachliche Probleme löst, müssen die Entwicklungsteams die Domäne verstehen. Ihr Verständnis der Strukturen und Regeln der Domäne formen sie zu einem fachlichen Modell, das in den Köpfen der Entwickler, in Form von Diagrammen, von Gesprächen, als Text und als Code existiert. Das fachliche Modell bildet im DDD den Kern eines Softwaresystems. Um diesen Kern herum braucht es selbstverständlich etwas Technik – Oberflächen, Schnittstellen, Persistenz, Kommunikation und so weiter –, um sinnvoll mit der Software arbeiten zu können.

Fachliche Modelle zu bauen, war keine originäre Idee von Eric Evans. Er griff auf objektorientierte Analyse und objektorientiertes Design zurück und ergänzte zwei wesentliche Konzepte, die Probleme beim Entwurf großer Systeme lösen. Evans beschreibt im taktischen Design (dazu später mehr) eine Mustersprache (das heißt zusammenhängende Muster), mit der fachliche Modelle entworfen werden können.

Je größeren Umfang ein fachliches Modell annimmt, desto mehr Inkonsistenzen werden darin sichtbar. Die Ursachen dafür liegen in der Domäne, denn viele fachliche Konzepte lassen sich nur kontextabhängig sinnvoll definieren. Sie in ein unternehmensweites Modell zu zwingen, führt zu “Gott-Klassen” und zyklischen Abhängigkeiten – mit anderen Worten zu einem großen, verworrenen Monolithen, der sich schlecht weiterentwickeln lässt. Evans schlägt vor, kontextabhängige fachliche Modelle zu entwickeln, die Konzepte und Verhalten eindeutig abbilden. Das führt zu einer fachlichen Modularisierung der Software: dem strategischen Design.

Strategisches DDD

Angenommen, Sie müssten Software für ein Kino bauen. Wie würden sie eine Kinokarte definieren? Die Antwort kann eigentlich nur heißen: Es kommt darauf an. Denn eine Kinokarte ist sowohl eine verkaufbare Einheit (mit Preis, Umsatzsteuer, Rabattmöglichkeit etc.) als auch eine Zutrittsberechtigung (mit Gültigkeit, validierbar etc.). Alle diese Eigenschaften und den kompletten Umgang mit einer Kinokarte in einem Modell abzubilden, führt zu den oben beschriebenen Problemen, die man im DDD als “Big Ball of Mud” [2] bezeichnet.

Ist eine Domäne zu groß, um als Ganzes verstanden und definiert zu werden, dann ist sie auch zu groß, um sie komplett in Software zu modellieren. In einem solchen Fall bildet man besser in sich abgeschlossene Teile einer Domäne in jeweils eigenen, kleineren Modellen ab. Auf diese Weise können die Software und das Entwicklungsteam wachsen. Das begrenzt die kognitive Last für die Beteiligten: Sie müssen nicht mehr ein ausuferndes Gesamtmodell verstehen, sondern nur noch überschaubare Modelle innerhalb klar abgegrenzter Kontexte (sogenannter Bounded Contexts). Das Ziel des strategischen Designs besteht darin, solche Bounded Contexts und ihre Beziehungen zueinander zu entwerfen.

Dazu teilt man zuerst die große und komplexe Domäne in Subdomänen auf. Das Ergebnis dieser Analyse sind die sprachlichen Grenzen, innerhalb derer sich fachliche Konzepte widerspruchsfrei und abgeschlossen modellieren lassen. Im einfachsten Fall wird eine Subdomäne zu einem Bounded Context. Überlegungen wie Teamgröße, technologische Komplexität, hohe Anforderungen an die User Experience, Skalierbarkeit und vieles mehr gilt es beim Design der Bounded Contexts ebenfalls zu berücksichtigen. Bounded Contexts zu entwerfen, heißt daher oft, Kompromisse einzugehen.

Manche Subdomänen sind für den Unternehmenserfolg entscheidender als andere. Im DDD unterscheidet man drei Arten von Subdomänen. Core Subdomains (meist nur Core Domains genannt) zeichnen ein Unternehmen aus und sind oft fachlich komplex. Die Software für Core Domains im eigenen Haus zu entwickeln, kann einen Wettbewerbsvorteil darstellen.

Supporting Subdomains bilden zwar nicht den fachlichen Kern eines Unternehmens ab, sind aber für die Aufgaben der Core Domains notwendig. Die fachlichen Modelle von Supporting Domains sind in der Regel unternehmensspezifisch, seltener branchenspezifisch. Software für Supporting Subdomains kann etwa ein Dienstleister bauen.

Generic Subdomains bieten keinen Wettbewerbsvorteil und sind nicht unternehmensspezifisch. Klassisches Beispiel ist die Lohnbuchhaltung, die für ein Unternehmen zwar essenziell ist, aber mit der man sich beispielsweise als Kinobetreiber nicht von seinen Mitbewerbern unterscheidet. Als Unternehmen will man für generische Subdomänen lieber Standardlösungen nutzen, als selbst Software zu bauen.

Bounded Contexts können als Module eines Monolithen oder als (Micro-)Services implementiert werden. Sie ziehen nicht nur Grenzen zwischen Modellen, sondern auch zwischen:

• den Verantwortlichkeiten von Teams (ein Team implementiert einen Bounded Context, kann aber auch mehrere implementieren),
• den Anforderungen, etwa als eigenes Backlog pro Bounded Context,
• im Quellcode, beispielsweise als Package-Baum oder Namespace, gegebenenfalls sogar in Form von eigenen Code-Repositories in einem Versionskontrollsystem und
• in der Datenhaltung.

Gerade die beiden letzten Punkte stoßen manchmal auf Vorbehalte: Führt das nicht zu dupliziertem Code und redundanten Daten? Tatsächlich hält sich die Duplikation in Grenzen, da jeder Bounded Context nur die für sein spezifisches Modell relevanten Daten hält (Abbildung 1).

Abbildung 3: Ein Klassendiagramm mit (links) und ohne (rechts) Berücksichtigung der Ubiquitous Language.

Eine Ubiquitous Language ist nicht einfach das Ergebnis einer fachlichen Analyse und kein Upfront-Design. Sie entsteht durch Gespräche zwischen Fachexperten und Entwicklungsteams. Sie entwickelt sich mit der Zeit weiter, was dann zu Refactorings im Code führt.

Die Ubiquitous Language und fachliche Modelle sind keine Einbahnstraße vom Fachbereich in die IT. Softwareentwicklung führt unter Umständen zu neuen fachlichen Konzepten. Im Kino-Beispiel kann etwa bei der Entwicklung eines Online-Kartenverkaufs der Begriff einer Empfehlung, die auf dem bisherigen Kaufverhalten beruht, neu in die Ubiquitous Language des Bounded Context eingeführt werden.

Collaborative Modeling

Wie findet man nun gute Kontextgrenzen und entwickelt Ubiquitous Languages und fachliche Modelle? Evans nennt Interviews, die Diskussion von konkreten Szenarien, prototypische Implementierungen und kurze Feedback-Zyklen. Darüber hinaus gibt er angehenden DDD-Praktikern allerdings wenig Handwerkszeug mit. Diese methodische Lücke für die Analyse von Domänen und das Design anwendungsbezogener Software schlossen andere. Beliebte Methoden sind beispielsweise Event Storming [7], Domain Storytelling oder Example Mapping [8].

Diese Methoden haben gemeinsam, dass sie Entwicklungsteams und Fachexperten zusammenbringen. Beide modellieren gemeinschaftlich, weswegen man diese Workshop-Formate unter dem Begriff Collaborative Modeling zusammenfasst. Der Werkzeugkasten des Collaborative Modeling gehört zu den wichtigsten Ergänzungen des DDD, und die Community entwickelt ihn intensiv weiter. Zudem kann Collaborative Modeling auch unabhängig von DDD nützlich sein, etwa bei der Anforderungsermittlung.

Was DDD (nicht) ist

DDD hat in den letzten 20 Jahren stark an Bedeutung gewonnen. Mit der weiten Verbreitung gehen allerdings auch Missverständnisse und überzogene Erwartungen einher. Mit einigen möchte ich hier aufräumen.

DDD ist weder ein Framework noch ein Architekturstil und auch keine Methode, denn es gibt keine Vorschrift, wie es anzuwenden ist. Es handelt sich auch nicht um eine Wasserfallmethode, in der die Modelle upfront entworfen werden [9]. Man muss die Technik keineswegs vollumfänglich vom Strategischen bis zum Taktischen nutzen. DDD bedeutet nicht, dass man Microservices bauen muss. Es zaubert auch keine Komplexität weg; komplexe Fachlichkeit bleibt auch mit DDD komplex.

Was DDD hingegen im Kern ausmacht, sind eine Reihe von Prinzipien [10]. Um Software für komplexe Fachlichkeit zu entwerfen, muss ein Entwicklungsteam (Entwickler, Tester, Analysten etc.) ein tiefes, gemeinsames Verständnis des Anwendungsgebiets aufbauen. Dabei werden sie von Fachexperten angeleitet. Dieses Verständnis erwächst aus der Sprache des Fachgebiets. Diese gilt es, gemeinsam, abgestimmt und eindeutig in einer Ubiquitous Language zu formalisieren.

Das Verständnis wird in einem Modell ausgedrückt, das Experten und Entwickler gemeinsam nutzen und das den Problemraum (im Gegensatz zum Lösungsraum) beschreibt. Das Modell muss die wesentliche Komplexität des Bereichs explizit ausdrücken. Komplexe Fachlichkeit kann man nicht effizient durch ein einziges, universelles Modell und eine universelle Sprache ausdrücken. Daher gilt es, sie in Bounded Contexts aufzuteilen. Das Modell, die Sprache und der Code sollten sich mit dem wachsenden Verständnis der Domäne mitentwickeln. Man wendet DDD im Sinne des Pragmatismus nicht zwingend überall an, sondern dort, wo es die größte Wirkung hat.

Dieser Artikel trägt hoffentlich dazu bei, die Idee von DDD klar zu kommunizieren. Wer noch tiefer in DDD einsteigen mag, findet im Kasten “Literaturtipps” meine Empfehlungen dazu. (jcb/jlu)