Definition „Domänen-getriebenes Design“

Was ist Domain-driven Design?

| Autor / Redakteur: chrissikraus / Stephan Augsten

Domain-driven Design sorgt dafür, dass auch in komplexen Software-Projekten keine Missverständnisse entstehen.
Domain-driven Design sorgt dafür, dass auch in komplexen Software-Projekten keine Missverständnisse entstehen. (Bild: Free-Photos - Pixabay.com / CC0)

Domain-driven Design, kurz DDD, beschreibt Vorgehensweisen, die komplexe Software-Projekte transparenter für alle Beteiligten machen sollen. Gleichzeitig definiert es eine Reihe von Techniken und Elementen, mit denen ein optimiertes Domänenmodell erreicht werden soll.

Ein komplexes Software-Projekt erfordert die aufwändige Koordination vieler Ressourcen. Fachexperten wissen exakt, welche Probleme es zu lösen gilt und Software-Entwickler wissen, mit welchen Mitteln das erreicht werden kann – doch die exakte Kommunikation zwischen diesen Personengruppen ist eine beträchtliche Herausforderung.

Domain-driven Design (DDD) ist ein Ansatz, der allen Beteiligten eine gemeinsame Plattform zur zweifelsfreien Kommunikation fachlicher Aspekte bieten soll. Neben wohldefinierten Vorgehensweisen schließt DDD eine einheitliche Sprache für Fachlichkeiten und ein Repertoire an Bauelementen und Techniken ein. Dadurch soll jeder Beteiligte stets genau wissen, wovon gesprochen wird und wie Vorgaben korrekt umzusetzen sind.

Der Aufwand für DDD ist sehr hoch, da alle Aspekte laufend standardisiert modelliert werden müssen. Doch für sehr komplexe und rentable Projekte lohnt der zusätzliche Einsatz, da Mehraufwand durch Missverständnisse und unklare Vorgaben stark reduziert werden kann.

Klar strukturieren mit Domänen

Beim DDD werden komplexe Zusammenhänge mithilfe klar abgegrenzter Domänen sauber modelliert. Sie bilden Fachlichkeit und Fachlogik des Anwendungsgebietes ab, meist die typischen Anforderungen und Zusammenhänge bestimmter geschäftlicher Vorgänge. Das Domänenmodell versucht, diese Anforderungen mit Konzepten aus der objektorientierten Entwicklung zu modellieren.

Einheitliche Sprache für alle

Für Domain-driven Design arbeiten Personen mit unterschiedlichsten Hintergründen zusammen. Damit die Kommunikation möglichst frei von Missverständnissen bleibt, ist ein einheitlicher Standard für die Beschreibung aller Komponenten des Projekts entscheidend: eine ubiquitäre Sprache. Es handelt sich um Formulierungen und Bezeichnungen, die von allen Beteiligten gleichermaßen verstanden wird. So kann von der Fachlichkeit bis zu einzelnen Methoden jeder Aspekt eindeutig ausgedrückt werden.

Die Sprache wird projektbegleitend weiterentwickelt, um die evolvierende Struktur des Systems zu unterstützen; auch Details wie die Änderung eines Klassennamens haben Einfluss. Wichtig: Die Sprache gilt immer nur im Kontext des jeweiligen Systems und kann in einem anderen Zusammenhang etwas völlig neues bedeuten.

Gut definierte Vorgehensweisen erleichtern komplexe Projekte

Damit die Integrität eines großen und komplexen Projekts gewahrt bleibt, gibt DDD bestimmte Vorgehensweisen vor. Je mehr Personen aus unterschiedlichen Teams und mit verschiedenen Hintergründen zusammenarbeiten sollen, desto wichtiger ist ein klarer Leitfaden.

Das Domänenmodell wandelt sich stetig mit wachsenden oder veränderten Anforderungen. Kontinuierliche Integration ist beim DDD dafür verantwortlich, diese Veränderungen ins Modell aufzunehmen und so die Einhaltung der Fachlichkeit zu gewähren. Die Vision der Fachlichkeit ist ein zentrales Element, das die Intentionen und Ziele der Kernfachlichkeit kurz beschreibt – und damit auch die Richtung, in die entwickelt werden soll.

Kernfachlichkeit

Die Kernfachlichkeit ist der Hauptnutzen des Domänenmodells, sozusagen der Kern der Anwendung. Es kann passieren, dass die Kernfachlichkeit sehr komplex und unübersichtlich wird. In solchen Fällen kann man mit einem separierten Kern modellieren. Hier wird die Kernfachlichkeit trotz enger Zusammenhänge mit anderen Modellelementen in ein eigenes Modul ausgelagert, um das System verständlicher und wartbarer zu gestalten.

Zudem gibt es noch das Konzept, einen geteilten Kern zu schaffen. Wenn die Kernfachlichkeit von vielen Teilen des Modells genutzt wird, welche selbst nur vage miteinander zusammenhängen, kann so eine gemeinsame Basis für alle Bereiche entwickelt werden. Schließlich gibt es noch Teile des Modells, die nicht zur Kernfachlichkeit gehören. Sie werden als generische Subfachlichkeiten in eigenen Modulen definiert und können daher gut ausgelagert oder durch Fremdsoftware abgedeckt werden.

Die Kontextgrenzen definieren, in welchem Teil des Modells welche Ressourcen und Ziele gelten. Für den nötigen Durchblick sorgt die Kontextübersicht. Sie dient als eine Art Karte, auf der alle Grenzen und Schnittstellen des Modells klar ersichtlich sind. Und die Beziehung zwischen den einzelnen, voneinander abhängigen Projektteams wird als Kunde-Lieferant-Beziehung abgebildet: Team A liefert die fachlichen Anforderungen, die Team B umsetzen soll.

Elemente des Domain-driven Design

Im DDD kann jede Domäne aus den folgenden Bestandteilen aufgebaut werden:

  • Module: fachliche Bestandteile der Domäne.
  • Entitäten: Objekte mit veränderlichen oder uneindeutigen Eigenschaften, die durch Ihre einzigartige Identität definiert sind (z. B. Personen).
  • Wertobjekte: Objekte, die durch ihre Eigenschaften eindeutig definiert sind und typischerweise unveränderlich bleiben.
  • Assoziationen: Beziehungen zwischen Objekten des Modells.
  • Aggregate: Einheit aus Objekten und deren Beziehungen.
  • Service-Objekte: fachlich relevante Funktionalitäten, die für mehrere Objekte der Domäne wichtig sind.
  • Fachliche Ereignisse: Spezielle Objekte registrieren fachlich relevante Ereignisse und machen sie für andere Domänenteile sichtbar (z. B. Ereignisse in einem Aggregat anderen Aggregaten der Domäne mitteilen).
  • Fabriken: Für komplexe Szenarien können verschiedene Erzeugungsmuster (meist factory oder builder patterns) herangezogen werden.
  • Repositories: saubere Trennung von Domänen- und Datenschicht für die Abstrahierung des Systems.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Aktuelle Beiträge zu diesem Thema

Lexikalische Grundlagen der C-Programmierung

Embedded-Software-Development

Lexikalische Grundlagen der C-Programmierung

C ist in der Embedded-Entwicklung eine überaus beliebte Programmiersprache. Ihre immense Flexibilität und Ausdrucksstärke birgt aber auch größte Gefahren für unerfahrene oder leichtfertige Programmierer. Daher ist es essentiell, sich ausgiebig mit den Grundlagen der Sprache vertraut zu machen. lesen

Datenmanagement als Erfolgsfaktor für Microservices

Domain-driven Design macht Datenmodelle verständlich

Datenmanagement als Erfolgsfaktor für Microservices

Durch die Unterstützung des DevOps-Ansatzes können Microservices dazu beitragen, sowohl die Effizienz des IT-Betriebs als auch die Art, wie Entwicklerteams arbeiten, zu verbessern. Eine der größten Herausforderungen kann das Datenmanagement sein. lesen

Best Practices beim Schwenk auf Microservices

Microservices fördern die Modernisierung

Best Practices beim Schwenk auf Microservices

Als zentraler Faktor für den Geschäftserfolg muss die IT eine hohe Flexibilität bieten. Der Einsatz von Microservices und Container-Technologie spielt bei der zügigen Umsetzung neuer Ideen eine entscheidende Rolle. lesen

Best Practices zu Microservice-Design, Logik und APIs

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

Wie sieht gutes Microservice-Design aus? Wenn Micro klein ist – wie klein sind dann die Services? Wie können APIs und Frameworks dafür aussehen? Was kann eine lose Kopplung gefährden? Und wie stellt man Datenpersistenz sicher? Ein Blick auf die Entwicklung aus einer System-Perspektive. lesen

Microservices-Anwendungen in der AWS Cloud

Mikrodienste als Architekturansatz

Microservices-Anwendungen in der AWS Cloud

„Wir möchten Microservices als Architekturmuster für unsere Anwendungen in der AWS Cloud nutzen, um die Agilität der Entwicklungsteams zu erhöhen. Welche Empfehlungen und Entwurfsmuster existieren für Microservices in der AWS Cloud?“ lesen

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45353292 / Definitionen)