[JAVA] Beantwortete Fragen zu DDD [Domain Driven Design]

Neulich besuchte ich Mediamax Japan (im Folgenden als MMJ bezeichnet) und hielt eine domänengesteuerte Design-Studiensitzung ab. Dort gab es eine Frage-und-Antwort-Sitzung, und wir beantworteten verschiedene spezifische Fragen, die auftauchten, als wir mit der Entwicklung mit domänengesteuertem Design begannen. Vielleicht hätten viele Leute ähnliche Fragen, deshalb möchte ich sie hier mit Genehmigung von MMJ vorstellen.

Wie man den Kontext teilt

Ist es in Ordnung, DB für mehrere Kontexte gemeinsam zu verwenden?
Ist es in Ordnung, kein Schema zu haben?

Wir empfehlen, das Schema für jeden Kontext auf ein Minimum zu beschränken. Weitere Informationen finden Sie im folgenden Artikel.

Bloss Context Implementation-Domain Driven Design Glossar

Für jede Funktion schneiden? Sollte der Kontext für jeden Benutzertyp getrennt werden?
Wie kann ich feststellen, ob der Kontext korrekt geschnitten wurde?

Das Kontextdesign verfügt nicht über ein Flussdiagramm, das entsprechend erstellt werden kann. In Wirklichkeit müssen wir sowohl aus konzeptioneller als auch aus umsetzungsbezogener Sicht denken. Als heuristischer Ansatz halte ich es für besser, aus mehreren Perspektiven Folgendes zu überprüfen.

• Ist es als Bereich geeignet, der die Bedeutung des Modells trennt? Hat ein Modell mehrere Bedeutungen?
• Hinweis auf kulturelle und organisatorische Grenzen
• Ist es angemessen, die Domäne (Problembereich) und nicht den Kontext (Lösungsbereich) zu unterteilen?
• Gibt es ein Implementierungsimage, um die Anwendung zu schneiden?
• Betrachten Sie es als eine Möglichkeit, Mikrodienste zu reduzieren
• Ist die Teamgröße angemessen?
• Als Faustregel gelten maximal 6-8 Personen.)
• Kannst du es gut nennen?
• Wenn Sie es nicht benennen können, haben Sie möglicherweise die falsche Idee.

Kann ich dasselbe Modell mit einem anderen Kontext teilen?

"Gleiches Modell" wird nicht geteilt.
Dies liegt daran, dass die Definition eines begrenzten Kontexts "ein expliziter Bereich ist, für den ein Modell gilt". Das Teilen in mehreren Kontexten verstößt gegen diese Definition.

Dies bedeutet jedoch nicht, dass "Objekte mit demselben Namen nicht in mehreren Kontexten existieren können".

"Definieren Sie Modelle mit demselben Namen, aber unterschiedlichem Verhalten in jedem Kontext."

Dann ist es notwendig, die Beziehung zwischen den Modellen im gesamten Kontext zu klären. Dies ist Kontextzuordnung.

Validierung

Wie soll ich die Validierung schreiben?

Es gibt verschiedene Arten von Validierungsgeschichten. Dieser Bereich ist das Material, über das ich schreiben möchte.

• Domäneneinschränkungen → Auf Domänenebene validieren, Ausnahmen auslösen und die Verarbeitung der Anwendung überlassen
• Anwendungsbeschränkungen → Schreiben Sie nach Bedarf

Über domänengesteuertes Design

Ist das Schreiben gut? Ich schreibe, während ich mir Sorgen mache. Gibt es eine bewährte Methode?

Da ist gar nichts! Lol vielleicht) Domain-gesteuertes Design ist unweigerlich in die Architekturgeschichte involviert, was viel Entscheidungsfindung erfordert. Zu diesem Zeitpunkt gibt es mehr als eine Option, die in Bezug auf das domänengesteuerte Design gewählt werden kann, und es ist notwendig, immer die Vor- und Nachteile und Kosten zu berücksichtigen und zu entscheiden, inwieweit das Konzept des domänengesteuerten Designs integriert werden soll.
Daher frage ich mich, ob es schwierig ist, etwas zu machen, das sagt "das ist die richtige Antwort". ..

Wenn Sie "Beispielcode" anstelle von "Best Practice" meinen, enthält das Buch Practice DDD Beispielcode für das Buch. Es kann gut sein, mit diesem Buch + Beispiel zu beginnen.

Wenn Sie das gesamte domänengesteuerte Design ordnungsgemäß ausführen, werden Sie in Überdesign verfallen. Wie lange soll ich es behalten?

Wie oben erwähnt, ist das Entwerfen eines domänengesteuerten Entwurfs ein Stapel feiner Entscheidungen.

Im Idealfall ist es am besten, die Vor- und Nachteile sowie die Kosten jedes Mal zu verstehen und eine ausgewogene Entscheidung zu treffen. Es gibt jedoch viele Dinge, die wir von Anfang an nicht verstehen, daher ist es notwendig, bis zu einem gewissen Grad fortzufahren. Darüber hinaus können wir das Design absichtlich beeinträchtigen, indem wir die Kostenleistung berücksichtigen.

Ich denke, es ist wichtig, den Grund später beantworten zu können, nicht "irgendwie", wenn man eine richtige Entscheidung trifft.

Über CQRS

Sind die durch die CQRS-Abfrage erhaltenen Daten kein Domänenmodell mehr?

Als welche Art von Objekt sollen die erfassten Daten behandelt werden? Ja, es ist in Ordnung zu glauben, dass das, was Sie mit dem Abfragemodell erhalten, nicht das Domänenmodell ist. Nennen wir das Modell für die Abfrage und trennen die Konzepte.

Ich benenne den Rückgabewert der Abfrage XxxDto und vermeide es, den Namen Dto an anderer Stelle zu verwenden.

Außerdem sehe ich es manchmal missverstanden.

*** CQRS bedeutet nicht, dass Sie im Domänenmodell keine DB-Abfragen für die Aktualisierungsverarbeitung durchführen können. *** ***

• Aktualisierungsverarbeitung → DB mit Domänenmodell abfragen und DB mit demselben Modell aktualisieren
• Referenzverarbeitung → DB-Abfrage mit Abfragemodell

Ist der Unterschied. Bitte seien Sie vorsichtig.

So interagieren Sie mit einem Domänenobjekt mit einem OR-Mapper
Derzeit wird jooq verwendet, um die Persistenz und das Laden aus der Datenbank zu implementieren. Gibt es eine Möglichkeit, die Implementierung wegzulassen?

In Bezug auf das ORM des Domänenmodells ist SpringDataJPA ein Konzept, das sich des domänengesteuerten Designs durchaus bewusst ist. Da die Implementierungsklasse des Repository automatisch über die Schnittstelle generiert wird, können die Probleme bis zu einem gewissen Grad eingespart werden. Es wird jedoch ein Kampf gegen die Spezifikationen des Ruhezustands sein, also wird es Ihnen gefallen.

Ich denke, der Vorteil der Abfrage besteht darin, dass Sie selbst effiziente Abfragen durchführen können. Ich glaube also nicht, dass Sie den Abfrageteil weglassen können. Wenn Sie MyBatis verwenden, wird die Zuordnung zwischen der Abfrage und dem Objekt, das sie empfängt, in gewissem Umfang unterstützt.

Zweck des domänengesteuerten Designs

Ich kenne nur die Freude am domänengetriebenen Design.
Was ist die Priorität zu schützen?

Welche Vorteile haben Priorität? Ich werde mehr darüber in einem anderen Artikel schreiben, aber ich werde Ihnen nur einen Überblick geben.

Erstens ist domänengesteuertes Design ungeeignet und für "Anwendungen mit komplexer Geschäftslogik" geeignet. In Fällen, in denen eine einfache CRUD ausreicht, ist der Aufwand sehr hoch.

Bei Anwendungen mit komplexer Geschäftslogik wird der Quellcode tendenziell kompliziert und die Entwicklungseffizienz nimmt im Verlauf der Entwicklung tendenziell ab. Andererseits denke ich, dass domänengesteuertes Design eine Gegenmaßnahme ist, um komplizierte Spezifikationen und Code gut zu kontrollieren.

Lassen Sie uns zunächst entscheiden, ob es für diesen Zweck geeignet ist.

Was interessiert Sie bei der Entwicklung?

Denken Sie, dass das Modell korrekt ist?

Die Botschaft des domänengesteuerten Designs ist, sich trotzdem auf das Modell zu konzentrieren.

Ich sage also nicht "mache die Modellierung angemessen und stelle etwas heraus, das vorerst funktioniert", sondern konzentriere mich nur darauf, ob das Modell korrekt zu sein scheint.

Welche Schicht ist für die Implementierung verantwortlich?

Dies ist ein kontroverser Punkt beim Entwerfen.

Gemäß der Verantwortungsdefinition der Domänenschicht und der Anwendungsschicht wird "Wo soll ich diese Implementierung schreiben?" Natürlich in gewissem Maße geleitet. Sie sollten während der Entwicklung immer darüber nachdenken. Dadurch wird eine solide Entwurfsrichtlinie erstellt, die zur Verbesserung der Implementierungswartung beiträgt.

Schichtverantwortung

Das Verständnis hier ist nicht eindeutig. Bitte sagen Sie mir, wie ich es gut trennen kann.

Ich möchte dies in einem anderen Artikel ausführlich schreiben.

• Domänenschicht: Gewährleistung der Integrität des zu systematisierenden Geschäfts
• Domänenmodell: Repräsentiert das Ergebnis der Modellierung eines Unternehmens   * Entity   * ValueObject   * DomainEvent
• Domain-Service
• Repository: Modellpersistenz / Wiederherstellung von Objekten vom Persistenzziel
• Factory: Objekterstellung (komplexe Dinge, die nicht der Entität überlassen werden können)
• DomainService: Verantwortlich dafür, dass nicht als ein Modell ausgedrückt werden kann
• Anwendungsschicht
• Anwendungsservice: Erfüllen Sie die Spezifikationen, indem Sie die von der Domänenschicht veröffentlichten Vorgänge kombinieren

Frei, um mit der Entwicklung fortzufahren

Welche Vereinbarung haben Sie, wenn Sie domänengesteuertes Design in Ihr Projekt einführen?

Es ist ein Inhouse-Service. .. Da ich jedoch zuvor bei SIer gearbeitet habe, werde ich auf der Grundlage dieser Erfahrung antworten.

Wenn es nur um Architektur geht, müssen wir zunächst Ihre Erlaubnis einholen, um die zu übernehmende Architektur auszuwählen? Ich denke, das ist der einzige Punkt. Wenn es kein Problem gibt, können Sie optional eine domänengesteuerte Entwurfsarchitektur übernehmen.

Das Problem betrifft den Entwicklungsprozess. Häufige Kommunikation ist erforderlich, da das domänengesteuerte Design immer mit der Erkennung im Dialog mit dem Domain-Experten (≒ Kunde) übereinstimmen soll. Es ist notwendig, mit dem Kunden zu vereinbaren, ob diese Gelegenheit rentabel sein kann.

Obwohl dies eine vollständige persönliche Meinung ist, muss nicht ausdrücklich angegeben werden, dass "wir domänengesteuertes Design machen werden", und wir haben uns auf die Geschichte geeinigt, dass "ich so bewusst sein möchte, ich brauche diese Frequenz". Ich denke, es ist gut, es zu nehmen. Sogar Ingenieure haben Schwierigkeiten, domänengesteuertes Design zu verstehen. Daher denke ich, dass es im Moment schwierig ist, die Unternehmensseite dazu zu bringen, so viel zu verstehen.

Was tun Sie, um das Modell mit Ihren Kunden zu teilen?

Das ER-Diagramm wird immer beibehalten, es gibt jedoch nur 3 Ingenieure.

Ich teile die Ehrlichkeit nicht mit der Geschäftsseite. Ich habe zum Zeitpunkt der Neuentwicklung mit dem Planer gearbeitet, aber im weiteren Verlauf habe ich nicht so viel erreicht.

Wenn überhaupt, ist es wie "Lasst uns die Wörter, die wir verwenden, zusammenbringen" (≒ allgegenwärtige Sprache). Um ehrlich zu sein, kenne ich das Bild, das Modelldiagramm mit Personen auf der Unternehmensseite zu teilen, nicht, und schließlich ist die Erkennung auf dem Bildschirm die beste, also untersuche ich, was daran gut ist.

Event-Sourcing

Hast du es vorgestellt? Ist es okay?

Ich habe es noch nicht getan.

Event Sourcing ist für Daten völlig ungeeignet, daher sollten Sie darauf basierend eine Entscheidung treffen.

Zum Beispiel Kaufhistorie usw.

• Bereich, in dem der Schaden groß ist, wenn Probleme auftreten
• Transaktionstyp, der Daten hinterlässt

Passend für. Es ist nicht erforderlich, eine einfache Verarbeitung wie das Abschließen / Unvollständigen von Aufgaben in die Ereignisbeschaffung einzubeziehen, und es ist erforderlich, die Vor- und Nachteile zu ermitteln.

Über Subdomains

Ich denke darüber nach, Schlüsselumhang zu verwenden. Sollte der Schlüsselumhang als separater begrenzter Kontext behandelt werden?

Ich denke, es ist besser, diesen Bereich sowohl aus dem Implementierungsimage als auch aus dem konzeptionellen Modell heraus zu betrachten. Es ist definitiv ein anderer Kontext, wenn es als Authentifizierungsserver unabhängig gemacht wird.
In diesem Fall, wie die von ihm empfangenen Informationen modelliert werden. Überlegen Sie, ob Persistenz erforderlich ist.

Über Architektur

Wie wird das dreischichtige + Domänenmodell der Architektur erstellt?

Ich persönlich empfehle die Zwiebelarchitektur. Weitere Informationen finden Sie im folgenden Artikel.

Was ist die am besten zugängliche Architektur, um mit domänengesteuertem Design zu beginnen

Übersicht über die domänengetriebene + Zwiebelarchitektur

Aber im Wesentlichen

*** Wenn das Domänenmodell in einer Form geschrieben ist, die von nichts abhängt, ist der Rest ein Fehler ***

ist. Danach möchte ich, dass Sie die auswählen, die zu Struktur und Begriffen passt.

So erstellen Sie ein Domänenobjekt aus Parametern, die von der UI-Ebene empfangen wurden

Lassen Sie uns zunächst Objekte nur in den folgenden beiden Mustern erstellen.

• Beim Erstellen eines neuen Objekts: Es wird empfohlen, es normalerweise mit dem Konstruktor des Objekts zu erstellen.
• Bei der Neuerstellung eines persistierten Objekts aus der Datenbank: Im Repository implementiert. Es ist besser, hier einen Rahmen zu verwenden.

Wichtig ist, dass *** persistierte Objekte nicht mit den Eingabewerten vom Bildschirm erstellt werden ***. Häufig wird der vom Bildschirmformular in der Aktualisierungsmethode empfangene Wert mit dem Wert vom Standardkonstruktor gepackt.

Stellen Sie für die Domänenschicht sicher, dass nur die Methoden verfügbar gemacht werden, mit denen die Konsistenz für die Anwendungsschicht sichergestellt werden kann.