Was ist Domain Driven Design?

Question

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?

Answer 1

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. Früher wurden diese Anforderungen unter Berücksichtigung der Beziehungen zwischen Klassen und Tabellen analysiert und ihr Design basierte auf den Beziehungen zwischen Datenbanktabellen:

• Bei großen Projekten mit komplexen Anforderungen ist es nicht sinnvoll, obwohl es eine großartige Entwurfsmethode für kleine Projekte ist.

• Wenn man es mit nicht technischen Personen zu tun hat, die kein technisches Konzept haben, kann dieser Konflikt zu großen Problemen in unserem Projekt führen.

DDD behandelt also das erste Problem, indem es das Hauptprojekt als Domäne betrachtet und jeden Teil dieses Projekts in kleine Stücke aufteilt, die wir als Bounded Context bezeichnen 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 Produkteigentümern ist, die nicht technisch sind, aber genügend Wissen über ihre Anforderungen haben

Im Allgemeinen ist die einfache Definition für Bereich ist das wichtigste Projekt, das den Eigentümern und anderen Teams Geld einbringt.

Answer 2

Ich möchte die Antworten der anderen nicht wiederholen, daher erkläre ich kurz einige häufige Missverständnisse

• Praktische Ressource: MODERNE, GRUNDSÄTZE UND PRAKTIKEN DES DOMAIN-DRIVEN DESIGNS von Scott Millett

• Es ist eine Methodik für komplizierte Geschäftssysteme. Bei der Kommunikation mit Wirtschaftsexperten werden alle technischen Fragen ausgeklammert.

• Es bietet dem gesamten Entwicklungsteam ein umfassendes Verständnis des (vereinfachten und destillierten Modells des) Geschäfts.

• es hält das Geschäftsmodell mit dem Code-Modell synchron, indem es allgegenwärtige Sprache (die Sprache, die vom gesamten Entwicklungsteam, den Geschäftsexperten, den Geschäftsanalysten, ... verstanden wird), die für die Kommunikation innerhalb des Entwicklungsteams oder mit anderen Teams verwendet wird

• Es hat nichts mit Projektmanagement zu tun . Obwohl es sich hervorragend für Projektmanagementmethoden wie Agile eignet.

• Sie sollten es vermeiden, es in Ihrem gesamten Projekt zu verwenden

  DDD betont die Notwendigkeit, den größten Aufwand auf den Kernbereich zu konzentrieren. Die Kern-Teildomäne ist der Bereich Ihres Produkts, der den Unterschied zwischen Erfolg und Misserfolg ausmachen wird. Es ist das Alleinstellungsmerkmal des Produkts, der Grund, warum es gebaut und nicht gekauft wird.

  Im Grunde genommen liegt es daran, dass es zu viel Zeit und Mühe kostet. Daher wird vorgeschlagen, die gesamte Domain in Subdomains aufzuteilen und sie nur in den Bereichen mit hohem Geschäftswert anzuwenden. (z. B. nicht in generischen Subdomains wie E-Mail, ...)

• Es handelt sich nicht um objektorientierte Programmierung. Es handelt sich meist um einen Problemlösungsansatz und ( manchmal ) müssen Sie in Ihren Domänenmodellen keine OO-Muster (wie die Gang of Four) verwenden. Einfach deshalb, weil sie von Business-Experten nicht verstanden werden können (sie wissen nicht viel über Factory, Decorator, ...). Es gibt sogar einige Muster in DDD (z.B. The Transaction Script, Table Module), die nicht zu 100% mit OO-Konzepten übereinstimmen.

Answer 3

Ich glaube, die folgende pdf-Datei vermittelt Ihnen ein umfassenderes Bild. Domänengesteuertes Design von Eric Evans

HINWEIS: Denken Sie an ein Projekt, an dem Sie arbeiten können, wenden Sie die kleinen Dinge an, die Sie verstanden haben und sehen Sie sich die besten Praktiken an. Das wird Ihnen helfen, Ihre Fähigkeiten in Bezug auf den Entwurfsansatz der Microservice-Architektur zu erweitern.

Answer 4

Verschaffen Sie sich ein unternehmensweites Verständnis für den Problembereich, indem Sie Entwicklung einer allgegenwärtigen Sprache (eines gemeinsamen mentalen Modells) für jeden Teilproblembereich. Verwenden Sie diese Sprache so weit wie möglich in den Lösungsdomänen (Code). Erst dann wählen Sie Technologien aus. Lassen Sie sich nicht von der Technologie leiten, sondern von der Problemdomäne oder dem Geschäft.