Kann bitte jemand (in kurzen Worten) erklären, was genau domain driven design ist? Ich sehe den Begriff ziemlich oft, aber ich verstehe nicht wirklich, was es ist oder wie es aussieht. Wie unterscheidet es sich von nicht-domänenorientiertem Design?
Kann mir jemand erklären, was ein Domain-Objekt ist? Wie unterscheidet sich ein Domain-Objekt von normalen Objekten?
EDIT:
Da dies ein Top-Ergebnis bei Google zu sein scheint und meine Antwort unten nicht, verweisen Sie bitte auf diese viel bessere Antwort:
https://stackoverflow.com/a/1222488/1240557
ALTE ANTWORT (nicht so vollständig :))
Um gute Software zu entwickeln, muss man wissen, was diese Software ist. Man kann kein Bankensoftwaresystem erstellen, wenn man nicht wenn man nicht genau weiß, worum es im Bankwesen geht, man muss den Bereich des Bankwesens verstehen.
Von: Domain Driven Design von Eric Evans.
In diesem Buch wird die DDD ziemlich gut beschrieben.
Registrieren Sie sich, um eine Zusammenfassung des Buches herunterzuladen o Laden Sie die Zusammenfassung direkt herunter .
Domain Driven Design ist eine Methodik und Prozessvorschrift für die Entwicklung komplexer Systeme, deren Schwerpunkt auf der Abbildung von Aktivitäten, Aufgaben, Ereignissen und Daten innerhalb einer Problemdomäne auf die technologischen Artefakte einer Lösungsdomäne liegt.
Der Schwerpunkt von Domain Driven Design liegt auf dem Verständnis der Problemdomäne, um ein abstraktes Modell der Problemdomäne zu erstellen, das dann mit einem bestimmten Satz von Technologien implementiert werden kann. Die Methodik des Domain Driven Design liefert Leitlinien dafür, wie diese Modell- und Technologieentwicklung zu einem System führen kann, das die Bedürfnisse der Nutzer erfüllt und gleichzeitig robust gegenüber Veränderungen im Problembereich ist.
Die Prozessseite von Domain Driven Design beinhaltet die Zusammenarbeit zwischen Domänenexperten, d. h. Personen, die die Problemdomäne kennen, und den Design-/Architektur-Experten, d. h. Personen, die die Lösungsdomäne kennen. Die Idee ist, ein gemeinsames Modell mit einer gemeinsamen Sprache zu haben, so dass Menschen aus diesen zwei verschiedenen Bereichen mit ihren unterschiedlichen Perspektiven die Lösung diskutieren, während sie tatsächlich eine gemeinsame Wissensbasis mit gemeinsamen Konzepten besprechen.
Das Fehlen eines gemeinsamen Verständnisses der Problemdomäne zwischen den Personen, die ein bestimmtes System benötigen, und den Personen, die das System entwerfen und implementieren, scheint ein Haupthindernis für erfolgreiche Projekte zu sein. Domain Driven Design ist eine Methode, um dieses Hindernis zu beseitigen.
Es geht um mehr als nur ein Objektmodell. Der Schwerpunkt liegt auf der gemeinsamen Kommunikation und der Verbesserung der Zusammenarbeit, so dass die tatsächlichen Bedürfnisse innerhalb des Problembereichs ermittelt und eine geeignete Lösung zur Erfüllung dieser Bedürfnisse geschaffen werden kann.
Bereichsorientiertes Design: Das Gute und das Herausfordernde gibt mit diesem Kommentar einen kurzen Überblick:
DDD hilft bei der Entdeckung der Top-Level-Architektur und informiert über die Mechanik und Dynamik des Bereichs, den die Software abbilden muss nachbilden muss. Konkret bedeutet dies, dass eine gut durchgeführte DDD-Analyse Missverständnisse zwischen Domänenexperten und Softwarearchitekten minimiert und Softwarearchitekten minimiert und die Anzahl der teuren Änderungswünsche für Änderungen. Durch die Aufteilung der Domänenkomplexität in kleinere Kontexte, vermeidet DDD, dass Projektarchitekten gezwungen sind, ein aufgeblähtes Objektmodell zu entwerfen Objektmodell zu entwerfen, bei dem viel Zeit für die Ausarbeitung von Implementierungsdetails verloren geht - zum Teil, weil die Anzahl der zu Teil, weil die Anzahl der Entitäten, mit denen man sich befassen muss, oft die Größe von Whiteboards in Konferenzräumen übersteigt.
Siehe auch diesen Artikel Bereichsorientiertes Design für die Dienstleistungsarchitektur die ein kurzes Beispiel liefert. Der Artikel enthält die folgende Kurzbeschreibung von Domain Driven Design.
Domain Driven Design befürwortet die Modellierung auf der Grundlage der Realität der Geschäftswelt, die für unsere Anwendungsfälle relevant ist. Da es nun älter wird und der Hype-Level abnimmt, vergessen viele von uns, dass der DDD-Ansatz wirklich wirklich dabei hilft, das Problem zu verstehen und die Software in Richtung das gemeinsame Verständnis der Lösung. Bei der Entwicklung von Anwendungen, DDD spricht über Probleme als Domänen und Subdomänen. Es beschreibt unabhängige Schritte/Bereiche von Problemen als begrenzte Kontexte, betont eine gemeinsame Sprache, um über diese Probleme zu sprechen, und fügt viele technische Konzepte wie Entitäten, Wertobjekte und aggregierte Root-Regeln zur die Implementierung zu unterstützen.
Martin Fowler hat eine Reihe von Artikeln geschrieben, in denen Domain Driven Design als Methodik erwähnt wird. Zum Beispiel dieser Artikel, BoundedContext bietet einen Überblick über das Konzept des begrenzten Kontexts aus dem Domain Driven Development.
In jenen jüngeren Tagen wurde uns geraten, ein einheitliches Modell der des gesamten Unternehmens zu erstellen, aber DDD erkennt an, dass wir gelernt haben, dass "total Vereinheitlichung des Domänenmodells für ein großes System nicht machbar oder kosteneffektiv ist". 1 . Stattdessen unterteilt DDD ein großes System in Bounded Contexts auf, von denen jeder ein vereinheitlichtes Modell haben kann - im Wesentlichen eine Art der Strukturierung von MultipleCanonicalModels.
Vous NUR CAN zum Verständnis des bereichsbezogenen Designs müssen Sie zunächst verstehen, was die folgenden Punkte sind:
Was ist eine Domäne?
Der Bereich, für den ein System gebaut wird. Flughafenmanagement, Versicherungsvertrieb, Coffee Shops, Orbitalflug, was auch immer.
Es ist nicht ungewöhnlich, dass eine Anwendung mehrere verschiedene Bereiche umfasst. Ein Online-Einzelhandelssystem könnte beispielsweise in den Bereichen Versand (Auswahl geeigneter Liefermethoden je nach Artikel und Zielort), Preisgestaltung (einschließlich Werbeaktionen und benutzerspezifischer Preisgestaltung nach z. B. Standort) und Empfehlungen (Berechnung verwandter Produkte anhand der Kaufhistorie) tätig sein.
Was ist ein Modell?
"Eine nützliche Annäherung an das vorliegende Problem." -- Gerry Sussman
Eine Mitarbeiterklasse ist kein echter Mitarbeiter. Sie modelliert einen echten Angestellten. Wir wissen, dass das Modell nicht alles über echte Angestellte erfasst, und das ist auch nicht der Sinn der Sache. Es soll nur das erfassen, was uns im aktuellen Kontext interessiert.
Unterschiedliche Bereiche können an verschiedenen Arten der Modellierung ein und derselben Sache interessiert sein. Zum Beispiel können die Gehaltsabteilung und die Personalabteilung Mitarbeiter auf unterschiedliche Weise modellieren.
Was ist ein Domänenmodell?
Ein Modell für einen Bereich.
Was ist Domain-Driven Design (DDD)?
Es handelt sich um einen Entwicklungsansatz, bei dem das Domänenmodell einen hohen Stellenwert hat und mit der Implementierung verbunden wird. DDD wurde von Eric Evans geprägt und ursprünglich entwickelt.
Entnommen aus aquí
Hier ist ein weiterer guter Artikel, den Sie sich ansehen können Bereichsbezogenes Design . wenn es sich bei Ihrer Bewerbung um etwas Ernsthafteres als eine Studienarbeit handelt. Die grundlegende Prämisse ist, alles um Ihre Entitäten herum zu strukturieren und ein starkes Domänenmodell zu haben. Unterscheiden Sie zwischen Diensten, die infrastrukturbezogene Dinge bereitstellen (wie das Versenden von E-Mails oder das Speichern von Daten), und Diensten, die tatsächlich Dinge tun, die Ihre Kerngeschäftsanforderungen sind.
Ich hoffe, das hilft.
Wie bei TDD & BDD konzentrieren Sie/ das Team sich mehr auf den Test und das Verhalten des Systems als auf die Code-Implementierung.
Ähnlich verhält es sich, wenn Systemanalytiker, Produkteigentümer, Entwicklungsteam und natürlich der Code - Entitäten/Klassen, Variablen, Funktionen, Benutzerschnittstellenprozesse - in derselben Sprache kommunizieren.
DDD ist ein Denkprozess. Bei der Modellierung eines Softwareentwurfs müssen Sie die Geschäftsdomäne/den Geschäftsprozess in den Mittelpunkt stellen und nicht Datenstrukturen, Datenflüsse, Technologie, interne und externe Abhängigkeiten.
Es gibt viele Ansätze zur Modellierung von Systemen mit DDD
In sehr naiven Worten: ein Objekt, das
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
