![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/02_Strategic.jpg\")
<\/p>\n\n\n\nDie Ver\u00e4nderungen, die unsere Welt in den letzten Jahren durchlaufen hat, f\u00fchren zu einer zunehmenden Komplexit\u00e4t in allen Bereichen. Damit steigen auch die Anforderungen an die Software, die wir nutzen. Wie kann der steigende Grad an komplexen Abl\u00e4ufen unserer Wirklichkeit in funktionsf\u00e4higen Softwaresystemen produktionsf\u00f6rdernd abgebildet werden? Der Ansatz des Domain-Driven Design hat sich f\u00fcr uns \u2013 der IT Sonix \u2013 bei gro\u00dfen und komplexen Softwareprojekten bew\u00e4hrt. Doch was ist Domain-Driven Design nun eigentlich? 2003 wurde der Begriff von Eric Evans mit seinem Buch Domain-Driven Design. Tackling Complexity in the Heart of Software etabliert. Im Grunde handelt es sich dabei um eine Sammlung von Werkzeugen und Techniken, die dabei helfen sollen, komplexe Software zu modellieren. Au\u00dferdem sind auch Denkweisen und Prinzipien zur Produktivit\u00e4tssteigerung zentraler Bestandteil des Domain-Driven Designs. Erreicht wird diese Steigerung der Produktivit\u00e4t durch eine besonders detailgetreue Orientierung an der Fachlichkeit und Wirklichkeit der abzubildenden Gesch\u00e4ftslogik.
Entwickelnde und Fachpersonen arbeiten bei der Modellierung eng zusammen und erschaffen so eine Begriffswelt, die bis in den Code hineinreicht. Interessant bei diesem Ansatz ist, dass das Modell erst einmal nur auf Sprache angewiesen ist und vorerst gar nichts programmiert werden muss. In Theorie wie Praxis l\u00e4sst sich das Domain-Driven Design in zwei gro\u00dfe Bereiche aufteilen: Strategic Design und Tactical Design.
W\u00e4hrend sich das Strategic Design mit der Architektur, also der Kontextabgrenzung und der Beziehung zwischen diesen besch\u00e4ftigt, k\u00fcmmert sich das Tactical Design um die Implementierung dieses erarbeiteten Models. Bevor wir jedoch im Folgenden tiefer in die Modellierung und den Code eindringen, wollen wir kurz die wichtigsten Begriffe des Strategic Designs erl\u00e4utern.
<\/p>\n\n\n\n
<\/p>\n\n\n\n
F\u00fcr die fachgerechte Abbildung realer Gesch\u00e4ftsprozesse in der Software liefert das Strategic Design wertvolle Konzepte: Domain Model, Ubiquitous Language sowie Bounded Context.
Das Domain Model befasst sich, wie der Name bereits verr\u00e4t, mit Domains. Domains bezeichnen hier die Wirklichkeit, also bspw. das gesamte Unternehmen bzw. die Fachlichkeit und nicht das Endprodukt, die Software. Diese Domains lassen sich wiederum in Subdomains untergliedern, wie bspw. Abteilungen, Teams oder Gesch\u00e4ftsprozesse. Nat\u00fcrlich ist das Domain Model nicht die Wirklichkeit, sondern eine Abstraktion dieser. Das geeignetste Mittel, Wirklichkeit in ein Model zu \u00fcberf\u00fchren, ist immer noch die Sprache, weshalb dieser im Domain-Driven Design auch besonders viel Aufmerksamkeit zukommt.
Der Schl\u00fcssel zum Erfolg liegt hier in der Ubiquitous Language. Ubiquitous bedeutet so viel wie allgegenwertig und genau das ist es auch, was Domain-Driven Design auszeichnet: Gemeinsam wird zwischen Fachpersonen und Entwickelnden eine Sprache erarbeitet, die von allen Beteiligten gesprochen wird und die von der Domain bis in den Code hinein konsistent ist. Begrenzt wird die Ubiquitous Language durch den Bounded Context.
Im Domain-Driven Design erh\u00e4lt ein Modell Bedeutung durch den Kontext, in dem es angewendet wird, und der Bounded Context bildet die Grenze eines Modells f\u00fcr einen bestimmten Zweck. Diese Abgrenzung ist besonders dann wichtig, wenn ein bestimmtes Konzept einer Domain durch verschiedene Modelle repr\u00e4sentiert wird. So hat der Begriff \u201eKunde bspw. f\u00fcr den Support eine andere Bedeutung als f\u00fcr den Sales-Bereich. Obwohl es sich um denselben Kunden im Sinne der Dom\u00e4ne handelt, k\u00f6nnen hier somit verschiedene Bounded Contexts bestimmt werden, die jeweils ein zu den Teilaufgaben des Kontexts passenden Customer modellieren.
Bounded Contexts f\u00fcr eine bestimmte Dom\u00e4ne zu definieren stellt eine der gr\u00f6\u00dften Herausforderungen im Domain-Driven Design dar. Hierf\u00fcr bieten sich kollaborative Methoden wie Event Storming oder Domain Story Telling an, bei denen Dom\u00e4nenexperten und Entwicklungsteams gemeinsam die jeweilige Dom\u00e4ne erforschen. Die daraus entstehenden Visualisierungen bieten eine erste Grundlage, m\u00f6glichst unabh\u00e4ngige Teile der Dom\u00e4ne zu identifizieren und als Bounded Context zu definieren.
Die gefundenen Bounded Contexts sind bereits essentiell f\u00fcr die Teamorganisation, da ein Kontext immer von einem Team betreut wird. Ein Team kann dabei auch mehrere Kontexte betreuen, aber niemals umgekehrt mehrere Teams einen Kontext. Mittels Context Mapping k\u00f6nnen weiterhin Abh\u00e4ngigkeiten zwischen den Kontexten und damit auch Kommunikationsarten zwischen den Teams beschrieben werden.
<\/p>\n\n\n\n
![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/03_Tactical.jpg\")
<\/p>\n\n\n\n
Sind das Domain Model, eine Ubiquitous Language sowie der Bounded Context einmal festgelegt, kann mit der Gestaltung und Implementierung spezifischer Softwarestrukturen und -Muster begonnen werden. Dies ist die Aufgabe des Tactical Design \u2013 mit seinen daf\u00fcr vorgesehenen Bausteinen: Value Object, Entity, Aggregate, Repository, Service, Factory. Diese reichen aus, um jede beliebige Domain zu modellieren.
Das Value Object ist der kleinste Baustein einer Domain und wird allein durch seine Eigenschaften gepr\u00e4gt \u2013 es hat keine Identit\u00e4t und seine Eigenschaften sind unver\u00e4nderbar, es kapselt primitiven Wert. Demnach k\u00f6nnen Value Objects, die dieselben Eigenschaften aufweisen, auch ausgetauscht werden. So wird im Domain-Driven Design bspw. f\u00fcr jede Postleitzahl ein eigenes Objekt generiert, etwas, das auch f\u00fcr andere komplexe Datentypen wie bspw. Geldbetr\u00e4ge genutzt werden kann. Jede Rechenoperation mit einem Value Object, das als Geldbetrag definiert ist, w\u00fcrde aus dem jeweiligen Ergebnis ein neues Value Object erstellen. Egal wie klein das Gegenst\u00fcck in der Wirklichkeit sein mag, im Domain-Driven Design gibt es f\u00fcr alles ein Modell.
Einer der Vorteile dieser Methode ist, dass sich f\u00fcr alles ein Objekt erzeugen l\u00e4sst und es sich dabei nicht nur um einen variablen Namen handelt, womit es nicht mit anderen (Strings) verwechselt werden kann. Der Wert des Objekts ist unver\u00e4nderbar. Ein Value Object kann auch aus mehreren Value Objects bestehen, wie bspw. eine Adresse, die sich dann aus den unterschiedlichen Value Objects Stra\u00dfe, Postleitzahl und Land zusammensetzt.
Den n\u00e4chsten wichtigen Baustein zum Modellieren bilden Entities. Im Gegensatz zu Value Objects verf\u00fcgen diese \u00fcber eine eindeutige Identit\u00e4t. Sie sind auch nicht von den ihnen zugewiesenen Eigenschaften abh\u00e4ngig \u2013 diese sind variabel und austauschbar und haben keinen Einfluss auf ihre Identit\u00e4t. Es sind die Entities, die das Herzst\u00fcck des gesamten Domain-Driven Design und am Ende auch der Software bilden.
Wenn wir bei unserem Musterfall mit den Stra\u00dfen und Postleitzahlen bleiben, so k\u00f6nnte es sich bspw. bei einer Einzelperson um ein Entity handeln. Die Einzelperson bleibt dieselbe Person, auch wenn sich ihre Adresse \u00e4ndert bzw. ist sie durch ihre Identit\u00e4t auch von einer anderen Einzelperson mit demselben Namen unterscheidbar. Entities k\u00f6nnen aber auch Business-Funktionen abbilden. Wird von den Fachpersonen festgelegt, dass es f\u00fcr den Gesch\u00e4ftsprozess notwendig ist, dass etwas eine bestimmte Wissensfunktion erf\u00fcllen muss, so wird daf\u00fcr meist ein eigenes Entity angelegt.
Im Domain-Driven Design werden Value Objects und Entities hierarchisch organisiert. Daf\u00fcr braucht es Aggregates. Anstatt zusammenh\u00e4ngende Logiken im Code in verschiedene Services zu unterteilen, was bei falschen Aufrufen zu Inkonsistenzen f\u00fchren kann, kapseln Aggregates s\u00e4mtliche Gesch\u00e4ftslogiken zu einem bestimmten Konzept (Bounded Context) \u2013 sie definieren Invarianten. Dadurch werden nach au\u00dfen nur Schnittstellen freigegeben, die immer einen konsistenten Zustand erzeugen.
F\u00fcr Business-Funktionen, die etwas an mehreren Entities ver\u00e4ndern sollen, wird immer das Aggregate verwendet. Hierf\u00fcr wird an dem Aggregate Root, welcher allen innerhalb des Aggregate angeordneten Entities \u00fcbersteht, etwas ge\u00e4ndert und nicht an den einzelnen Entities selbst. Nur so kann sichergestellt werden, dass diese Funktionen bei allen Entities, wo es notwendig ist, auch durchgef\u00fchrt werden. Die Operationen an den Aggregate Roots entsprechen Transaktionen \u00e4hnlich Ans\u00e4tzen, die mit Datenbanken arbeiten.
Um eine Menge an Aggregate Roots repr\u00e4sentieren zu k\u00f6nnen, ben\u00f6tigt es Repositories. Sie sind innerhalb der Domain v\u00f6llig unabh\u00e4ngig von Persistenz-Technologie und meist nur eine Abstraktion dieser. Erst durch das Infrastructure Layer werden sie implementiert.
F\u00fcr Fachlichkeiten, die nicht durch ein Entity oder Value Object abgebildet werden k\u00f6nnen, gibt es die M\u00f6glichkeit, diese als Service zu definieren. Auch wenn es sich dabei um eine Seltenheit handelt, da mit den oben genannten Bausteinen nahezu alles festgelegt werden kann, so k\u00f6nnen Services doch hilfreich sein, um gewisse Funktionalit\u00e4ten, die bspw. nicht hierarchisch funktionieren oder gar nicht erst als Entit\u00e4t existieren, zu modellieren.
Die Factory erm\u00f6glicht es, die Verantwortung f\u00fcr das Erstellen komplexer Aggregates in ein eigenes Objekt zu verlagern.
<\/p>\n\n\n\n
![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/04_Architecture.jpg\")
<\/p>\n\n\n\n
Neben diesen rein dom\u00e4nenspezifischen Bausteinen ist es notwendig auch technische Aspekte zu implementieren. Diese sollen so organisiert werden, dass eine klare Trennung des Zwecks und lose Kopplung untereinander entsteht. Hierf\u00fcr bietet das Domain-Driven Design ein Layered-Architecture-Modell. Dieses besteht aus: Infrastructure, Interfaces, Application und Domain.
Die Infrastructure unterst\u00fctzt dabei alle anderen Layer und besteht oft aus Implementierungen von Abstraktionen der Domain. Beispiele daf\u00fcr sind Datenbank-Repositories, Message Backend, REST Clients und externe Bibliotheken.
Als n\u00e4chster Layer folgen Interfaces, die die Schnittstellen nach au\u00dfen darstellen, wie bspw. REST-Endpunkte oder Message Handler. Sie bilden die oberste Schicht und d\u00fcrfen daher auf alle darunterliegenden zugreifen. Kernpunkt des Domain-Driven Designs ist, dass die Domain keine Abh\u00e4ngigkeit zur Infrastructure entwickelt. Die Regel hierbei lautet, dass Zugriffe nur von oben nach unten erfolgen d\u00fcrfen und nicht umgekehrt. Es sind jedoch auch Abk\u00fcrzungen m\u00f6glich. So kann es durchaus sein, dass das Interfaces Layer direkt auf die Domain zugreift, ohne den Umweg \u00fcber den Application Layer. H\u00e4ufig geschieht dies, wenn nur etwas ausgelesen werden soll, z. B. \u00fcber ein REST-Interface. Der Interface Layer k\u00fcmmert sich um die Serialisierung und Validierung. Primitive Daten wie bspw. eine einfache ID werden hier in ein Value Object umgewandelt, was gleichzeitig auch die Validierung der Eingabeparameter ist. Use Cases oder die Domain-Logik fallen nicht in seinen Zust\u00e4ndigkeitsbereich.
F\u00fcr die Use Cases ist der Application Layer zust\u00e4ndig. Hier werden komplette Use Cases aufgef\u00fchrt und koordiniert jedoch ohne Domain-Logik. Datenbanktransaktionen sowie Sicherheitsmechanismen wie bspw. User-Rechte finden meist auf dieser Ebene statt. Gerade bei User-Rechten kann es manchmal zu Schwierigkeiten kommen, wenn es um die Zuordnung des richtigen Layers geht. Wie sehr sind diese Teil der Domain oder nur technisches Hilfsmittel? Handelt es sich dabei um etwas rein Technisches, dann ist im Domain-Driven Design der Application Layer daf\u00fcr vorgesehen. Wichtig dabei ist, dass dieser Layer unabh\u00e4ngig vom aufrufenden Interface \u2013 also der dar\u00fcberliegenden \u2013 Schicht ist. Der Applications Layer sollte zur Ein- bzw. Ausgabe nur Objekte aus der Domain verwenden, da sie diese nur benutzt und nicht umwandelt. Es wird empfohlen, dass jede Methode dieser Schicht nur mit maximal einem Aggregate Root interagiert, um die Komplexit\u00e4t gering zu halten. Erfordert ein Use Case eine Interaktion mit mehreren Entities, so kann dies ein Zeichen f\u00fcr die Notwenigkeit eines weiteren Aggregate Roots sein, welches diese kapselt und die Konsistenz und Invarianten dieser sicherstellt.
Den letzten Layer \u2013 das Herz der Software \u2013 bildet die Domain selbst. Er enth\u00e4lt s\u00e4mtliche Domain-Logik \u2013 gegebenenfalls auch nur als Abstraktion \u2013 und orientiert sich konsequent an die im Strategic Design definierte Ubiquitous Language.
Da das Domain Model keine Abh\u00e4ngigkeit zu allen anderen Schichten hat, kann Domain-Driven Design auch mit einem Hexagon- oder Onion Layer Model realisiert werden. Es wird immer von au\u00dfen nach innen zugegriffen und jede Schicht hat ihre eigene Berechtigung.
<\/p>\n\n\n\n
F\u00fcr die Umsetzung komplexer und gro\u00dfer Projekte ist f\u00fcr uns vor allem das Layered Architecture Model von gro\u00dfem Nutzen. Die klar getrennten Schichten helfen uns dabei, die Gesch\u00e4ftslogik vollkommen unabh\u00e4ngig von den eingesetzten Technologien zu denken. \u00c4ndert sich bspw. etwas in den Gesch\u00e4ftsregeln, so muss es nur im Domain Layer angepasst werden, ohne ma\u00dfgebliche Auswirkungen auf die anderen Schichten. Zudem erm\u00f6glicht Domain-Driven Design auch anhand des Codes im Domain Layer die Gesch\u00e4ftslogik ohne gro\u00dfen Aufwand auszulesen, da diese eben ohne Technologien wie bspw. Datenbanken, REST-Schnittstellen etc. auskommt. Gleichzeitig k\u00f6nnen auch neue Technologien implementiert werden, ohne die Fachlichkeit zu besch\u00e4digen.
Da die Anwendung von Domain-Driven Design mit sehr gro\u00dfem Aufwand verbunden ist, empfiehlt sich dieser Ansatz vorrangig f\u00fcr sehr gro\u00dfe und besonders komplexe Projekte. Hier kann diese Methode jedoch auf nahezu ganzer Linie punkten, da durch die isolierte Domain-Schicht und eben durch die konsistent in allen Schichten verwendete Sprache (Ubiquitous Language) \u2013 bis in den Code hinein \u2013 alles aus der Fachlichkeit wiedergefunden werden kann.<\/p>\n","protected":false},"excerpt":{"rendered":"
Die Ver\u00e4nderungen, die unsere Welt in den letzten Jahren durchlaufen hat, f\u00fchren zu einer zunehmenden Komplexit\u00e4t in allen Bereichen. Damit steigen auch die Anforderungen an die Software, die wir nutzen. Wie kann der steigende Grad an komplexen Abl\u00e4ufen unserer Wirklichkeit in funktionsf\u00e4higen Softwaresystemen produktionsf\u00f6rdernd abgebildet werden? Der Ansatz des Domain-Driven Design hat sich f\u00fcr uns […]<\/p>\n","protected":false},"author":4,"featured_media":932,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung"],"acf":[],"yoast_head":"\n