Was ist Domain Driven Design (DDD)?

Erstens, wenn Sie nicht wissen, dass Sie es brauchen, ist es möglich, dass Sie es nicht brauchen. Wenn Sie die von DDD gelösten Probleme nicht erkennen, haben Sie diese Probleme möglicherweise nicht. Selbst DDD-Befürworter weisen häufig darauf hin, dass DDD nur für große Projekte (> 6 Monate) gedacht ist.

Angenommen, Sie lesen zu diesem Zeitpunkt noch. Meine Einstellung zu DDD lautet wie folgt:

Bei DDD geht es darum, Ihre Software zu einem Modell eines realen Systems oder Prozesses zu machen. Bei der Verwendung von DDD sollten Sie eng mit einem Domänenexperten zusammenarbeiten, der die Funktionsweise des realen Systems erklären kann. Wenn Sie beispielsweise ein System entwickeln, das das Platzieren von Wetten auf Pferderennen regelt, ist Ihr Domain-Experte möglicherweise ein erfahrener Buchmacher.

Zwischen Ihnen und dem Domain-Experten erstellen Sie eine allgegenwärtige Sprache (UL), die im Grunde eine konzeptionelle Beschreibung des Systems darstellt. Die Idee ist, dass Sie in der Lage sein sollten, die Systemaktivitäten so aufzuschreiben, dass der Domänenexperte sie lesen und überprüfen kann, ob sie korrekt sind. In unserem Wettbeispiel würde die allgegenwärtige Sprache die Definition von Wörtern wie "Rennen", "Wette", "Gewinnchancen" usw. enthalten.

Die von der UL beschriebenen Konzepte bilden die Grundlage für Ihr objektorientiertes Design. DDD bietet klare Anleitungen zur Interaktion Ihrer Objekte und hilft Ihnen, Ihre Objekte in die folgenden Kategorien zu unterteilen:

• Wertobjekte, die einen Wert darstellen, der untergeordnete Teile haben kann (z. B. ein Datum kann einen Tag, einen Monat und ein Jahr haben)
• Entitäten, die Objekte mit Identität sind. Beispielsweise hat jedes Kundenobjekt eine eigene Identität, sodass wir wissen, dass zwei Kunden mit demselben Namen nicht derselbe Kunde sind
• Aggregierte Wurzeln sind Objekte, die andere Objekte besitzen. Dies ist ein komplexes Konzept und basiert auf der Annahme, dass einige Objekte nur dann sinnvoll sind, wenn sie einen Eigentümer haben. Zum Beispiel ist ein 'Order Line'-Objekt nicht sinnvoll, ohne dass ein' Order 'dazugehört. Wir sagen also, dass der Order die aggregierte Wurzel ist, und dass Order Line-Objekte nur über Methoden im Order-Objekt bearbeitet werden können

DDD empfiehlt auch mehrere Muster:

• Repository , ein Muster für die Persistenz (Speichern und Laden Ihrer Daten, normalerweise in/aus einer Datenbank)
• Factory , ein Muster für die Objekterstellung
• Service, ein Muster zum Erstellen von Objekten, die Ihre Hauptdomänenobjekte manipulieren, ohne selbst Teil der Domäne zu sein

An dieser Stelle muss ich sagen, dass Sie, wenn Sie noch nie von diesen Dingen gehört haben, DDD nicht für Projekte verwenden sollten, für die Sie eine Frist haben. Bevor Sie DDD versuchen, sollten Sie mit Entwurfsmuster und nternehmensentwurfsmuster vertraut sein. Wenn Sie diese kennen, ist DDD viel leichter zu verstehen. Und, wie oben erwähnt, gibt es eine kostenlose Einführung in DDD von InfoQ (wo Sie auch Vorträge über DDD finden können).