it-swarm.com.de

Was ist domänengetriebenes Design?

Kann jemand bitte (kurz und knapp) erklären, was genau domänengetriebenes Design ist? Ich sehe den Begriff ziemlich oft, verstehe aber wirklich nicht, wie er aussieht oder wie er aussieht. Wie unterscheidet es sich von nicht domänengetriebenem Design?

Kann jemand auch erklären, was ein Domain-Objekt ist? Wie unterscheidet sich Domäne von normalen Objekten?

150
Calanus

BEARBEITEN:

Da dies ein Top-Ergebnis bei Google zu sein scheint und meine Antwort unten nicht ist, beziehen Sie sich bitte auf diese viel bessere Antwort:

https://stackoverflow.com/a/1222488/1240557

ALTE ANTWORT (nicht so vollständig :))

Um eine gute Software zu erstellen, müssen Sie wissen, was diese Software ist dreht sich alles um. Sie können kein Bankensoftware-System erstellen, wenn Sie nicht ein gutes Verständnis davon haben, worum es beim Bankgeschäft geht, muss man die Domäne des Bankwesens verstehen.

Von: Domain Driven Design von Eric Evans.

Dieses Buch beschreibt DDD ziemlich gut.

Registrieren Sie sich, um eine Zusammenfassung des Buches herunterzuladen oder Laden Sie die Zusammenfassung direkt herunter .

88
Mikael Östberg

Domain Driven Design ist eine Methodik und Prozessvorschrift für die Entwicklung komplexer Systeme, deren Schwerpunkt darin liegt, Aktivitäten, Aufgaben, Ereignisse und Daten innerhalb einer Problemdomäne in die Technologieartefakte einer Lösungsdomäne abzubilden.

Der Schwerpunkt von Domain Driven Design besteht darin, die Problemdomäne zu verstehen, um ein abstraktes Modell der Problemdomäne zu erstellen, das dann in einer bestimmten Reihe von Technologien implementiert werden kann. Domain Driven Design als Methodik gibt Richtlinien vor, wie diese Modellentwicklung und Technologieentwicklung dazu führen kann, dass ein System den Anforderungen der Benutzer entspricht, die es verwenden, und gleichzeitig robust gegenüber Änderungen im Problembereich ist.

Die Prozessseite von Domain Driven Design umfasst die Zusammenarbeit zwischen Domänenexperten, Personen, die die Problemdomäne kennen, und Design-/Architekturexperten, Personen, die die Lösungsdomäne kennen. Die Idee ist, ein gemeinsames Modell mit gemeinsamer Sprache zu haben, damit Menschen aus diesen zwei unterschiedlichen Domänen mit ihren zwei verschiedenen Perspektiven die Lösung diskutieren, diskutieren sie tatsächlich eine gemeinsame Wissensbasis mit gemeinsamen Konzepten.

Das Fehlen eines gemeinsamen Problems der Problemdomänen zwischen den Personen, die ein bestimmtes System benötigen, und den Personen, die das System entwerfen und implementieren, scheint ein wesentliches Hindernis für erfolgreiche Projekte zu sein. Domain Driven Design ist eine Methodik zur Behebung dieses Hindernisses.

Es ist mehr als ein Objektmodell. Der Fokus liegt auf der gemeinsamen Kommunikation und der Verbesserung der Zusammenarbeit, sodass die tatsächlichen Bedürfnisse in der Problemdomäne ermittelt und eine geeignete Lösung erstellt werden kann, die diese Anforderungen erfüllt.

Domänengetriebenes Design: Das Gute und das Herausfordernde gibt einen kurzen Überblick mit diesem Kommentar:

DDD hilft dabei, die Top-Level-Architektur zu erkennen und über die .__ zu informieren. Mechanik und Dynamik der Domäne, für die die Software erforderlich ist replizieren. Konkret bedeutet dies, dass eine gut durchgeführte DDD-Analyse durchgeführt wird minimiert Missverständnisse zwischen Domain-Experten und Software Architekten, und es reduziert die nachfolgende Anzahl teurer Anfragen für den Wandel. Durch die Aufteilung der Domänenkomplexität in kleinere Kontexte kann DDD vermeidet, dass Projektarchitekten dazu gezwungen werden, ein aufgeblähtes Objekt zu entwerfen Modell, bei dem viel Zeit beim Training verloren geht Implementierungsdetails - zum Teil, weil die Anzahl der Entitäten für Umgang mit wächst oft über die Größe von Whiteboards im Konferenzraum hinaus.

Siehe auch diesen Artikel Domain Driven Design for Services-Architektur , der ein kurzes Beispiel enthält. Der Artikel enthält die folgende Miniaturansicht des domänengesteuerten Designs.

Domain Driven Design befürwortet die Modellierung basierend auf der Realität von Geschäft als relevant für unsere Anwendungsfälle. Da wird es jetzt älter und Hype-Level abnehmen, vergessen viele von uns, dass der DDD-Ansatz wirklich hilft beim Verstehen des anstehenden Problems und beim Entwerfen von Software in Richtung das gemeinsame Verständnis der Lösung. Beim Erstellen von Anwendungen... DDD spricht über Probleme als Domänen und Subdomains. Es beschreibt Unabhängige Schritte/Problembereiche als begrenzte Kontexte, hebt ein .__ hervor. gemeinsame Sprache, um über diese Probleme zu sprechen, und fügt viele technische Konzepte wie Entitäten, Wertobjekte und aggregieren Stammregeln zu Unterstützung bei der Umsetzung.

Martin Fowler hat eine Reihe von Artikeln verfasst, in denen Domain Driven Design als Methodik erwähnt wird. Dieser Artikel, BoundedContext , bietet beispielsweise einen Überblick über das Konzept des beschränkten Kontextes von Domain Driven Development.

In jüngerer Zeit wurde uns geraten, ein einheitliches Modell der .__ zu bauen. Das gesamte Geschäft, aber DDD erkennt an, dass wir gelernt haben, dass "die Gesamtuniversalisierung des Domänenmodells für ein großes System nicht machbar oder kostengünstig ist" 1 . Stattdessen teilt DDD ein großes .__ auf. System in Bounded Contexts, von denen jeder ein einheitliches Modell -.__ haben kann. im Wesentlichen ein Weg zur Strukturierung von MultipleCanonicalModels.

34

Hier ist ein weiterer guter Artikel, den Sie unter Domain Driven Design lesen können. Wenn Ihre Bewerbung etwas Ernstes ist als eine College-Aufgabe. Die Grundvoraussetzung besteht darin, alles rund um Ihre Entitäten zu strukturieren und ein starkes Domänenmodell zu haben. Unterscheiden Sie zwischen Diensten, die infrastrukturbezogene Dinge bereitstellen (z. B. das Senden von E-Mails, persistente Daten), und Dienstleistungen, die tatsächlich Dinge erledigen, die Ihre Kernanforderungen erfüllen.

Hoffentlich hilft das.

10
Nilesh

Sie KÖNNEN NUR können domänengestütztes Design verstehen, indem Sie zunächst Folgendes verstehen:

Was ist eine Domain?

Das Feld, für das ein System erstellt wird. Flughafenmanagement, Versicherungsverkauf, Cafés, Orbitalflug, wie Sie es nennen.

Es ist nicht ungewöhnlich, dass eine Anwendung mehrere verschiedene Domänen umfasst. Zum Beispiel könnte ein Online-Handelssystem in den Bereichen Versand (Funktionieren der Lieferung je nach Artikel und Bestimmungsort), Preisgestaltung (einschließlich Werbeaktionen und benutzerspezifische Preisberechnung nach Standort) und Empfehlungen (Berechnung) relevant sein Produkte nach Kaufhistorie).

Was ist ein Modell?

"Eine nützliche Annäherung an das vorliegende Problem." - Gerry Sussman

Eine Employee-Klasse ist kein echter Mitarbeiter. Es modelliert einen echten Mitarbeiter. Wir wissen, dass das Modell nicht alles über echte Mitarbeiter erfasst, und darum geht es nicht. Es soll nur erfassen, was uns für den aktuellen Kontext interessiert.

Unterschiedliche Domänen können an verschiedenen Arten interessiert sein, um dasselbe zu modellieren. Beispielsweise können die Gehaltsabteilung und die Personalabteilung die Mitarbeiter auf unterschiedliche Weise modellieren.

Was ist ein Domain-Modell?

Ein Modell für eine Domain.

Was ist Domain-Driven Design (DDD)?

Es ist ein Entwicklungsansatz, der das Domänenmodell tief einschätzt und mit der Implementierung verbindet. DDD wurde von Eric Evans geprägt und ursprünglich entwickelt.

Von hier ausgesondert

10
Edwin Ikechukwu

DDD (Domain Driven Design) ist ein nützliches Konzept für die Analyse der Anforderungen eines Projekts und den Umgang mit der Komplexität dieser Anforderungen. Zuvor analysierten die Mitarbeiter diese Anforderungen unter Berücksichtigung der Beziehungen zwischen Klassen und Tabellen, und tatsächlich basierten ihre Entwürfe auf Datenbanktabellen Beziehungen ist es nicht alt, aber es hat einige Probleme:

  • In großen Projekten mit komplexen Anforderungen ist dies nicht sinnvoll, obwohl dies eine großartige Möglichkeit zum Entwerfen für kleine Projekte darstellt.

  • wenn Sie es mit Personen zu tun haben, die kein technisches Konzept haben, kann dieser Konflikt zu großen Problemen in unserem Projekt führen.

Daher behandelt DDD das erste Problem, indem es das Hauptprojekt als Domäne betrachtet und jeden Teil dieses Projekts in kleine Teile aufteilt, die wir als beschränkter Kontext kennen und die keinen Einfluss auf andere Teile haben. Und das zweite Problem wurde mit einer allgegenwärtigen Sprache gelöst, die eine gemeinsame Sprache zwischen technischen Teammitgliedern und Produktbesitzern ist, die nicht technisch sind, aber über ausreichende Kenntnisse über ihre Anforderungen verfügen

Im Allgemeinen ist die einfache Definition für Domain das Hauptprojekt, mit dem die Eigentümer und andere Teams Geld verdienen.

1
sajadre

Ich glaube, das folgende PDF gibt Ihnen das größere Bild. Domain Driven Design von Eric Evans

HINWEIS: Stellen Sie sich ein Projekt vor, an dem Sie arbeiten können, wenden Sie die kleinen Dinge an, die Sie verstanden haben, und sehen Sie sich Best Practices an. Es wird Ihnen helfen, Ihre Fähigkeiten im Hinblick auf den Entwurf einer Mikrodienstarchitektur zu erweitern.

0
Hedego

Wie in TDD und BDD konzentrieren Sie/Team sich am meisten auf den Test und das Verhalten des Systems als auf die Code-Implementierung.

Auf ähnliche Weise können Systemanalytiker, Produktbesitzer, Entwicklungsteam und natürlich die Code - Entitäten/Klassen, Variablen, Funktionen und Benutzeroberflächenprozesse mit derselben Sprache kommunizieren, die als Domain Driven Design bezeichnet wird

DDD ist ein Denkprozess. Bei der Modellierung eines Softwaredesigns müssen Sie den Geschäftsbereich/-prozess im Mittelpunkt der Aufmerksamkeit halten und nicht auf Datenstrukturen, Datenflüsse, Technologie, interne und externe Abhängigkeiten.

Es gibt viele Ansätze zum Modellieren von Systerm mit DDD 

  • event-Sourcing (mit Ereignissen als einzige Wahrheitswahrheit)
  • relationale Datenbanken
  • graph-Datenbanken
  • mit funktionalen Sprachen

Domain-Objekt:

In ganz naiven Worten ein Objekt was

  • hat einen auf Geschäftsprozess/Fluss basierenden Namen 
  • hat die vollständige Kontrolle über seinen internen Zustand, d. h. Methoden zur Manipulation des Zustands verfügbar machen.
  • erfüllen Sie stets alle betrieblichen Invarianten/Geschäftsregeln im Zusammenhang mit ihrer Verwendung.
  • folgt dem Prinzip der Einzelverantwortung 
0
Nitin babariya