Serienartikel: Domain-gesteuerte Designkommentarserie
Was ist die einfachste Architektur, um mit dem domänengesteuerten Design-Little-Hands-Labor zu beginnen
Übersicht über die domänengetriebene + Zwiebelarchitektur - Labor für kleine Hände
Wie ich in diesen Artikeln schrieb, bin ich DDD Wir verwenden den Begriff Zwiebelarchitektur, wenn wir uns für die Schichtarchitektur von entscheiden. Ich habe es bisher verschiedenen Leuten erklärt, und ich habe über Ebenenverantwortlichkeiten als einen Punkt gesprochen, der es leicht macht, im Verständnis stecken zu bleiben, also werde ich das erklären.
Onion Architecture Is Interesting - DZone Java
Beschreibung jeder in diesem Artikel geschriebenen Ebene
japanische Übersetzung
Ich habe es bisher verschiedenen Leuten erklärt, aber in vielen Fällen konnte ich es mit der obigen Erklärung nicht richtig machen. Besonders wenn ich *** anwendungsspezifische Logik *** sage, ist das Wort "Anwendung" mehrdeutig, so dass die Leute es anders erhalten und es nicht gut zu passen scheint.
Daher habe ich mich kürzlich auf das Thema Verantwortlichkeiten konzentriert und versucht, Folgendes zu erklären.
Es mag ein wenig irreführend oder gegenläufig sein zu sagen, dass die Verantwortung der Domänenschicht "Datenintegrität" ist, aber ich wage es, dies mit einem Schwerpunkt auf einfacher Kommunikation zu sagen.
Ich werde unten ausführlich erklären.
Was bedeutet es, auf dieser Ebene "Datenintegrität sicherzustellen"?
Ein konkretes Codebeispiel finden Sie im Artikel Was drückt Domänenwissen in einem Modell aus. Wir möchten jedoch "nur Methoden verfügbar machen, die die Konsistenz mit den oberen Ebenen gewährleisten können (Sichtbarkeit nicht öffentlich machen).
Im Beispiel des obigen Artikels lautet die Regel der Datenintegrität: "Eine Aufgabe kann nur dreimal an einem Tag verschoben werden." Um dies zu gewährleisten, müssen Kontrollen wie "Aufzeichnen der Anzahl der Verschiebungen beim Verschieben einer Aufgabe" und "Überprüfen der Anzahl der Verschiebungen vor dem Verschieben und Fehler machen, wenn sie das Dreifache überschreiten" durchgeführt werden.
Eine Methode, die dies nicht garantiert, ist etwa "Sie können das Fälligkeitsdatum frei ändern, ohne die Anzahl der Aufgabenverschiebungen zu berücksichtigen". Dies ist genau das, dem alle Setter in der öffentlichen Einstellung ausgesetzt sind, wie z. B. die ActiveRecord-Musterobjekte.
Indem wir nur die Methoden veröffentlichen, die korrekt gesteuert werden können, streben wir einen Zustand an, in dem "die Integrität der Daten nicht beeinträchtigt werden kann, egal wie hart die obere Schicht arbeitet".
Ich schrieb, dass die Verantwortung dieser Schicht darin besteht, "die von der Domänenschicht bereitgestellten Methoden zu kombinieren und einen Anwendungsfall zusammenzustellen".
Wie unterscheidet sich dies von den Verantwortlichkeiten der Domänenschicht?
Nehmen wir als weiteres Beispiel an, die Domänenschicht stellt eine "Methode zum Ändern der Adresse eines Benutzers" und eine "Methode zum Ändern einer festen Telefonnummer" als unabhängige öffentliche Methoden bereit.
Dies bedeutet, dass die Domänenschicht "die unabhängige Aktualisierung der Adresse und der festen Telefonnummer aus Gründen der Datenintegrität ermöglicht".
Andererseits können in der Anwendungsschicht die folgenden Anwendungsfälle durch Kombinieren der obigen Verfahren realisiert werden.
Ob der Aktualisierungsvorgang unabhängig oder gleichzeitig ausgeführt werden soll, kann in der Anwendungsschicht je nach dem zu realisierenden Anwendungsfall frei kombiniert werden.
Wenn die Domänenschicht hingegen sagt: "Aus Gründen der Datenintegrität können Adressen und feste Telefonnummern nur gleichzeitig aktualisiert werden", muss die Anwendungsschicht die Anforderungen erfüllen.
Anwendungsfälle (insbesondere in Ihren eigenen Webanwendungen) können sich je nach Strategie in einem kurzen Zyklus ändern. Aber wird sich die Integrität der Daten entsprechend ändern? Die Antwort wäre nein. Indem Sie Elemente mit unterschiedlichen Lebenszyklen in jeder Schicht einschränken, können Sie das Design widerstandsfähig gegen Änderungen machen.
Abschließend möchte ich über die Vorzüge einer solchen Überlagerung schreiben.
Beim Entwerfen einer DDD muss immer darüber nachgedacht werden, wo dieser Prozess verantwortlich ist. Dies ist ein sehr wichtiges Konzept, das für das Layering-Design von DDD von zentraler Bedeutung ist. Bitte verwenden Sie es als Referenz beim Entwerfen.
Recommended Posts