[JAVA] Was ist domänengesteuertes Design, das versucht, [DDD] zu lösen?

Was sagt Eric Evans zur Definition des domänengesteuerten Designs In dem Artikel zitierte ich Eric Evans 'Definition von Domain Driving und übersetzte sie wie folgt ins Japanische.

1. Konzentrieren Sie sich auf die Kernkomplexität und die Möglichkeiten der Domäne
2. Untersuchen Sie Modelle in Zusammenarbeit mit Domain- und Software-Experten
3. Schreiben Sie eine Software, die diese Modelle explizit darstellt
4. Sprechen Sie in einer allgegenwärtigen Sprache in einem begrenzten Kontext

Dabei wurden die wichtigen Punkte nicht spezifiziert.

*** Warum müssen wir so etwas wie die vier in der Definition tun? *** darüber.

Was genau versucht *** domänengesteuertes Design zu lösen? *** ***

Was versucht domänengesteuertes Design zu lösen?

DDD ist eine der Softwareentwicklungsmethoden. Lassen Sie uns zunächst über den Zweck der Softwareentwicklung nachdenken.

Warum entwickeln Menschen Software? Es kann gesagt werden, dass *** ein Problem des Ziels lösen soll, das in Software *** umgewandelt werden soll.

Dieses "in Software zu konvertierende Ziel" wird als "Domäne" bezeichnet. Die Software stammt aus einer bestimmten Domäne und ist stark in diese Domäne eingebunden.

Wie geht DDD bei der Softwareentwicklung vor? Siehe auch Was Eric Evans zur Definition des domänengesteuerten Designs sagt [DDD-Referenz](http: / Am Anfang von /domainlanguage.com/ddd/reference/) befindet sich eine Beschreibung wie diese.

• Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling.
• Viele Projekte haben keinen nennenswerten Gewinn aus der *** Modellierung. *** DDD extrahiert erfolgreiche Muster aus Projekten, die *** dramatisch von der *** Modellierung profitiert haben.

Das heißt, DDD ist

*** Steigern Sie den Wert Ihrer Software durch Domain-Modellierung ***

Wir verfolgen den Ansatz.

Was bedeutet es also, von der Modellierung zu profitieren?

Was bedeutet "Nutzen aus der Modellierung"?

Lassen Sie uns zunächst die Definition des Modells überprüfen. Nach Eric Evans 'Definition *** "eine Abstraktion eines bestimmten Aspekts von Dingen zur Lösung eines Problems" ***. Die reale Welt kann nicht so wie sie ist in Software verwandelt werden. Es muss so abstrahiert werden, dass es zur Problemlösung geeignet ist, und das Produkt ist ein Modell.

Betrachten wir ein konkretes Beispiel.

Beispiel: Tägliche Berichtsmodellierung

Zum Beispiel habe ich ein Geschäft, um einen täglichen Bericht auf Papier zu schreiben. "Ich habe keinen Platz, um den täglichen Bericht physisch abzulegen, deshalb möchte ich ihn online ausfüllen." Nehmen wir an, es ist systematisiert, um das Problem zu lösen.

In der realen Welt gibt es viele Informationen.

Der Name der Person, die den Tagesbericht geschrieben hat, das Datum und der Inhalt des Tagesberichts,
Anzahl der Seiten, Preis, Material, Käufer, Broschüre, um einen täglichen Bericht zu schreiben
Ort zum Schließen des Tagesberichts, Stift zum Schreiben des Tagesberichts, Ort, Zeit ...

Es gibt unendlich viele Informationen, je nachdem, wie ausgeschnitten werden soll.

Wie oben erwähnt, ist es unmöglich und nicht notwendig, all dies in Software zu integrieren.

Daher haben wir in dieser Software Folgendes als die Informationen definiert, die zur Lösung des obigen Problems erforderlich sind.

Der Name der Person, die den Tagesbericht geschrieben hat, das Datum und der Inhalt des Tagesberichts

Dies ist das Modell.

Was ist ein gutes Modell?

Was ist ein gutes Modell? Angesichts der Definition von "einer Abstraktion eines bestimmten Aspekts von Dingen zur Lösung eines Problems" kann ein gutes Modell dieses *** Problem lösen, und ein schlechtes Modell, das dies nicht kann.

Was ist das Modell, das das Problem nicht lösen kann? Betrachten Sie das Beispiel eines täglichen Berichts.

Bei der Analyse des täglichen Berichtsgeschäfts (im Folgenden: Domain) Tatsächlich wird der tägliche Bericht zum Austausch von Feedback-Kommentaren meines Vorgesetzten verwendet, und ich stellte fest, dass dies ohne diese Systematisierung nicht beseitigt werden kann.

Das aktuelle tägliche Berichtsmodell enthält jedoch nur die Informationen "die Person, die den täglichen Bericht schreibt, das Datum und den Inhalt des täglichen Berichts". Dies kann das Konzept des Feedbacks nicht ausdrücken und das in der Domain vorhandene Problem "Ich möchte den täglichen Bericht online vervollständigen" nicht lösen.

Mit anderen Worten, das vorherige Modell ist unzureichend und kein gutes Modell.

Wie macht man ein gutes Modell und profitiert von der Modellierung?

Ansatz, um von der Modellierung zu profitieren

Wie Sie dem täglichen Berichtsfall entnehmen können, ist es zur Lösung des Problems erforderlich, die Domäne richtig zu verstehen und im Modell wiederzugeben. Um einen Mehrwert als Software zu erzielen, ist es außerdem erforderlich, diesen vom Modell auf die Software zu übertragen.

Daher unterteilt sich DDD grob in die beiden in der folgenden Abbildung gezeigten Ansätze.

1. Vertiefen Sie Ihr Verständnis von Domänen und verbessern Sie Ihr Modell weiter

Im obigen Beispiel haben wir festgestellt, dass das Problem ohne Verständnis der Domäne nicht richtig gelöst werden kann. Wie verstehen Sie die Domain?

Ja, Sie müssen jemanden fragen, der mit *** Domains *** vertraut ist.

Wie oft hörst du zu?

Soll ich es modellieren, die Software freigeben und dann Feedback erhalten? Es ist nicht schwer vorstellbar, dass es besser ist, die Wahrnehmungen bei der Erstellung des *** Modells zu berücksichtigen. Sobald Sie Ihr Modell erstellt und aktualisiert haben, ist es besser, Ihre Wahrnehmungen jedes Mal in Einklang zu bringen, und Sie haben weniger Nacharbeit und eine bessere Chance, Ihr Modell frühzeitig zu verbessern.

Mit anderen Worten, um Ihr Verständnis der Domäne zu vertiefen *** Es ist wichtig, so oft wie möglich Feedback von Personen zu erhalten, die mit der Domain vertraut sind ***.

Definierter Ansatz

DDD benennt und definiert diesen Ansatz.

Personen, die mit Domains vertraut sind, werden als "Domain-Experten" bezeichnet. Im Prinzip verwenden wir dieselben Wörter wie Domain-Experten und "erkunden" Modelle gemeinsam.

Um Erkennungsdifferenzen zu vermeiden und die Konvertierungskosten für verschiedene Wörter zu senken, ist es derzeit auch ein Prinzip, dass alle Domain-Experten und Entwickler "dieselben Wörter verwenden" und dieses Wort "allgegenwärtige Sprache" ist. Wir nennen es ***.

Da es nicht realistisch ist, "ein Modell, das der ganzen Welt gemeinsam ist" und "ein Modell, das dem gesamten Unternehmen gemeinsam ist" zu sagen, ist es auch eine Grenze, dies aus der Idee heraus zu klären, über den Anwendungsbereich dieses Modells zu entscheiden. Der angehängte Kontext ist "***".

In diesem Artikel finden Sie eine ausführliche Erläuterung dieses Bereichs. Bounded Context Concept Bounded Context Implementation

2. Reflektieren Sie das Modell kontinuierlich in der Software

Da sich das Modell weiter verbessert, müssen die Änderungen natürlich in der Software berücksichtigt werden. In der Lage zu sein, damit umzugehen, ist eine große Voraussetzung für *** Software!

Da sich das normale Modell in der Nähe der Datenbank befindet, können Änderungen unter Berücksichtigung der Kosten leicht so weit wie möglich vermieden werden. Ohne eine solide Vorbereitung auf architektonischer Ebene wird es schwierig sein, diese Nachfrage zu befriedigen.

Auf der anderen Seite in DDD

• Schreiben Sie eine Software, die das Modell so ausdrückt, wie es ist
• Verwenden Sie bewährte DDD-Entwurfsmuster

Wir befürworten den Ansatz.

Schreiben Sie eine Software, die ein Modell darstellt

Damit ist die Modell-Software-Zuordnung klar *** Wir sind bestrebt, das Modell so weit wie möglich in Software auszudrücken ***. Ein konkretes Beispiel finden Sie im Artikel Was drückt Domain-Wissen mit einem Modell aus?. Bitte gib mir.

Dies ist aus praktischen Gründen.

Je komplexer das Modell ist, desto schwieriger ist es, seine Zuordnung zu verstehen, und desto schwieriger ist es, häufige Änderungen widerzuspiegeln. Selbst wenn Sie versuchen, die Modellinformationen in einem Dokument zu beschreiben, ist das Dokument häufig veraltet, und es besteht eine hohe Wahrscheinlichkeit, dass das Wissen über das Modell nicht wiedergegeben oder im falschen Zustand übertragen wird.

"Allgegenwärtig" im oben erwähnten Konzept der allgegenwärtigen Sprache bedeutet "Überall", was "***" in den Aussagen von Domain-Experten, Entwicklern und *** "Software bedeutet. ..

Verwenden Sie bewährte DDD-Entwurfsmuster

Dies ist genau das, was als sogenannte "taktische DDD" bekannt ist. Um häufigen Codeänderungen standzuhalten, ist ein hohes Maß an Wartbarkeit erforderlich. Zu diesem Zweck werden Entitäten und Repositorys als *** hochkohäsive Entwurfsmuster *** definiert, die durch verschiedene Projekte abgeleitet werden.

Allgemein anerkannt (und wahrscheinlich) als Vorteil von DDD, *** "Schreiben von Code, der einfach zu pflegen ist" war nicht wirklich der Hauptzweck ***. Die richtige Position ist, dass Muster wie berühmte Entitäten Nebenprodukte waren, um ihre Ziele zu erreichen.

Abgesehen davon wird das Muster, das nur taktisches DDD einführt, manchmal als "leichtes DDD" bezeichnet. Ich persönlich halte es für sinnvoll, wenn Sie sich vorstellen, "nur ein gutes Design zu integrieren, das häufigen Modellwechseln standhält". Es gibt jedoch ein Modell, das der Idee zugrunde liegt. Wenn Sie also ohne dieses Modell darüber nachdenken, denke ich, dass Falten irgendwohin führen werden.

Zusammenfassung

Warum machst du überhaupt DDD? Ich denke, es gab nur wenige Möglichkeiten, sich damit zu befassen. Wenn Sie dies zuerst verstehen, können Sie meiner Meinung nach mit Absichten arbeiten, anstatt nur den in DDD definierten Ansatz zu verfolgen.

Wenn Sie mehr wissen wollen

Wir haben ein Buch für diejenigen veröffentlicht, die zum ersten Mal DDD lernen, oder für diejenigen, die tatsächlich begonnen haben und mit Schwierigkeiten konfrontiert sind.

Domain Driven Design Modeling / Implementierungshandbuch

Beginnend mit einer Erklärung des "Zwecks von DDD" und des "Modells", die dazu neigen, verloren zu gehen Wir möchten die Attraktivität und die Auswirkungen von DDD anhand von Beispielen für die konkrete Modellierung und Implementierung erfahren.

Der Abschnitt "Kapitel 1 DDD-Übersicht" dieses Buches enthält eine detailliertere Erläuterung des Inhalts dieses Artikels. Bitte kaufen Sie, wenn Sie möchten.

Auf Twitter senden wir auch Fragen zu DDD und akzeptieren Fragen über einen Dienst namens "Question Box". Bitte folgen Sie mir, wenn Sie möchten.

@little_hand_s