it-swarm.com.de

Anwendungsschicht gegen Domänenschicht?

Ich lese Domain-Driven Design von Evans und diskutiere gerade über die Schichtarchitektur. Ich habe gerade festgestellt, dass Anwendungs- und Domänenebenen unterschiedlich sind und getrennt sein sollten. In dem Projekt, an dem ich arbeite, sind sie irgendwie gemischt und ich kann den Unterschied erst erkennen, wenn ich das Buch gelesen habe (und ich kann nicht sagen, dass es mir jetzt sehr klar ist).

Meine Fragen, da beide die Logik der Anwendung betreffen und keine technischen und Präsentationsaspekte aufweisen sollen, welche Vorteile bietet es, eine Grenze zwischen diesen beiden zu ziehen?

49
Louis Rhys

Ich habe kürzlich selbst DDD gelesen. Als ich zu diesem Abschnitt kam, war ich angenehm überrascht, als ich herausfand, dass ich dieselbe 4-Schicht-Architektur entdeckte wie Evans. Wie @lonelybug hervorhob, sollte die Domänenschicht vollständig vom Rest des Systems isoliert sein. Es muss jedoch etwas UI-spezifische Werte (Abfragezeichenfolgen, POST Daten, Sitzung usw.) in Domänenobjekte übersetzen. Hier kommt die Anwendungsschicht ins Spiel. Ihre Aufgabe ist die Übersetzung Hin und her zwischen der Benutzeroberfläche, der Datenschicht und der Domäne, wodurch die Domäne effektiv vor dem Rest des Systems verborgen wird.

Ich sehe jetzt viele ASP.NET MVC-Anwendungen, in denen sich fast die gesamte Logik in den Controllern befindet. Dies ist ein fehlgeschlagener Versuch, die klassische 3-Schicht-Architektur zu implementieren. Controller sind schwer zu testen, da sie so viele UI-spezifische Probleme haben. Tatsächlich ist es an und für sich eine ernsthafte Herausforderung, einen Controller so zu schreiben, dass er sich nicht direkt mit den "HTTP-Kontext" -Werten befasst. Im Idealfall sollte der Controller nur eine Übersetzung durchführen, die Arbeit koordinieren und die Antwort zurückspucken.

Es kann sogar sinnvoll sein, eine grundlegende Validierung in der Anwendungsschicht durchzuführen. Es ist in Ordnung, wenn die Domain davon ausgeht, dass die darin enthaltenen Werte sinnvoll sind (ist dies eine gültige ID für diesen Kunden und stellt diese Zeichenfolge ein Datum/eine Uhrzeit dar). Die Validierung mit Geschäftslogik (kann ich in der Vergangenheit ein Flugticket reservieren?) Sollte jedoch für die Domänenschicht reserviert werden.

Martin Fowler kommentiert tatsächlich, wie die meisten Domain-Layer sind heutzutage flach . Obwohl die meisten Leute nicht einmal wissen, was eine Anwendungsschicht ist, stellt er fest, dass viele Leute ziemlich dumme Domänenobjekte und komplexe Anwendungsebenen erstellen, die die Arbeit der verschiedenen Domänenobjekte koordinieren. Ich bin selbst schuld daran. Das Wichtigste ist nicht, eine Ebene aufzubauen, weil es Ihnen in einem Buch gesagt wurde. Die Idee ist, Verantwortlichkeiten zu identifizieren und unseren Code basierend auf diesen Verantwortlichkeiten zu trennen. In meinem Fall hat sich die "Anwendungsschicht" auf natürliche Weise weiterentwickelt, als ich die Unit-Tests erhöht habe.

37
Travis Parks

Ausgehend von Martin Fowlers Mustern des Unternehmensdesigns sind die häufigsten Schichten:

  • Präsentation - Dies sind Ansichten, Präsentationsvorlagen, die die Interaktionsschnittstelle für Ihre Anwendung generieren (ich verwende Interaktion, falls andere Systeme über Webdienste oder RMI auf Ihre Anwendung zugreifen und daher möglicherweise keine Benutzeroberfläche sind). Dies schließt auch Controller ein, die entscheiden, wie und wie Aktionen ausgeführt werden.

  • Domäne - Hier befinden sich Ihre Geschäftsregeln und -logik, Ihre Domänenmodelle werden definiert usw.

  • Datenquelle - Dies ist die Datenzuordnungsschicht (ORM) und Datenquelle (Datenbank, Dateisystem usw.)

Wie zeichnen Sie die Grenzen zwischen den drei Ebenen:

  • Fügen Sie Ihren Modellen oder Domänenobjekten keine präsentationsspezifische Logik hinzu

  • Fügen Sie keine Logik in Ihre Seiten und Controller ein, d. H. Logik zum Speichern von Objekten in der Datenbank, Erstellen von Datenbankverbindungen usw., wodurch Ihre Präsentationsschicht spröde und schwer zu testen ist

  • Verwenden Sie ein ORM, mit dem Sie Ihren Datenquellenzugriff und Ihre Aktionen vom Modell entkoppeln können

  • Folgen Sie dem Thin Controller - Fat Model Paradigma, Controller dienen zur Steuerung des Ausführungsprozesses, der nicht ausgeführt wird. Weitere Informationen finden Sie unter http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models- Skinny-Controller / und http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model Modell, Ansicht und Controller,

Die Domain-Schicht modelliert das Geschäft Ihrer Anwendung. Dies sollte Ihre klare Interpretation der Regeln, der Komponentendynamik und des Status zu jedem Zeitpunkt sein.

Die Anwendungsschicht ist "besorgt" über die Definition der Jobs, die zur Ausführung einer bestimmten Anwendungsaufgabe ausgeführt werden müssen. Hauptsächlich ist es für das Mandat der erforderlichen Domänenarbeit verantwortlich nd interagiert mit anderen (externen oder nicht) Diensten.

Für Beispiel verfügt meine Finanzsoftwareanwendung über eine Benutzeroperation zum Ändern des Status einer Modellentität (Entität wie in DDD [89] definiert):

  • "Der Einsatzleiter kann einen Finanzvorschlag genehmigen".

Als Bewerbungsprozess muss ich jedoch neben allen Modellfolgen dieser Operation eine interne Mitteilung an andere Benutzer der Anwendung senden. Diese Art von Arbeit wird in der Anwendungsschicht "orchestriert". Ich möchte nicht, dass meine Domain-Schicht darüber nachdenkt, einen Messaging-Dienst zu leiten. (und dies ist sicherlich keine Verantwortung für die Präsentationsschicht). Eines ist jedoch sicher: Ich benötige eine neue Ebene, da sich in meiner Domänenebene alles um das Kerngeschäft und in meiner Präsentationsschicht alles um das Interpretieren von Benutzerbefehlen und das Präsentieren von Ergebnissen geht.

Anmerkungen:

  • Business ist eines dieser Wörter, die häufig zu mehreren Interpretationen seiner Bedeutung führen, aber Sie können sicher viele Beispiele finden und darüber in DDD sprechen.
  • DDD steht für Domain-Driven Design Buch von Eric Evans und Nummer in eckigen Klammern für die Seitenzahl.
17
José Andias

Die Domänenschicht sollte als Isolationsschicht konzipiert werden. Dies bedeutet, dass die Geschäftslogik und -regeln nicht durch Änderungen des Codes (in der Anwendungsschicht, der Präsentationsschicht und der Infrastrukturschicht) beeinflusst werden sollten.

Es wird angenommen, dass die Anwendungsschicht einige Funktionen zur Bereitstellung einer Systemschnittstelle (Anwendungsschnittstelle) (denken Sie, dies sei wie eine API oder RESTful) bietet. Benutzer können sich beispielsweise in einem System anmelden. Bei dieser Anwendungsaktion (Anmeldung) sind Anwendungsschichtcodes die Clientcodes für die Domänenschicht (oder Infrastrukturschicht), in denen das Benutzerdomänenobjekt abgerufen und die Methoden dieses Objekts zum Implementieren des Objekts angewendet werden Anmeldefunktion.

Die Anwendungsschicht sollte auch als Isolationsschicht konzipiert sein. Dies bedeutet, dass das Verhalten der Anwendung nicht durch Änderungen des Codes (in der Präsentationsschicht, der Domänenschicht und der Infrastrukturschicht) beeinflusst werden sollte.

6
stevesun21
  • Anwendungsschicht und Domänenschicht fallen beide in den Implementierungsbereich.
  • Die Anwendungsschicht fungiert als API.
  • Domain Layer fungiert als Implementierung der API, enthält Geschäftslogik und wird daher auch als Business Logic Layer bezeichnet.

(enter image description here

3
Premraj

Der Zweck der domänengesteuerten Modellierung besteht darin, das Domänenmodell wesentlich zu trennen und es ohne Abhängigkeiten von anderen Ebenen und anderen Anwendungsproblemen existieren zu lassen.

Auf diese Weise können Sie sich ohne Ablenkung auf die Domäne selbst konzentrieren (z. B. die Koordination zwischen der Benutzeroberfläche und den Persistenzdiensten).

3
Oded

Der Hauptgrund für diese Grenzen ist Trennung von Bedenken . Der Code, der auf den Datenspeicher zugreift, sollte sich nur um den Zugriff auf den Datenspeicher kümmern müssen. Es sollte nicht für die Durchsetzung von Regeln für die Daten verantwortlich sein. Darüber hinaus sollte die Benutzeroberfläche dafür verantwortlich sein, Steuerelemente in der Benutzeroberfläche zu aktualisieren, Werte aus Benutzereingaben abzurufen und sie in etwas zu übersetzen, das die Domänenschicht verwenden kann, und nicht mehr. Es sollte Operationen aufrufen, die von der Domänenschicht bereitgestellt werden, um alle erforderlichen Aktionen auszuführen (z. B. diese Datei speichern). Ein aufgerufener Webdienst sollte für die Konvertierung vom Übertragungsmedium in etwas verantwortlich sein, das die Domänenschicht verwenden kann, und dann die Domänenschicht aufrufen (die meisten Tools erledigen einen Großteil dieser Arbeit für Sie).

Diese Trennung bietet Ihnen bei ordnungsgemäßer Implementierung die Möglichkeit, Teile Ihres Codes zu ändern, ohne andere zu beeinflussen. Beispielsweise muss möglicherweise die Sortierreihenfolge einer zurückgegebenen Sammlung von Objekten geändert werden. Da Sie wissen, dass die für die Datenmanipulation verantwortliche Schicht (normalerweise die Geschäftslogikschicht) diese Aufgaben übernimmt, können Sie leicht erkennen, wo der Code geändert werden muss. Sie müssen nicht ändern, wie es aus dem Datenspeicher oder einer der Anwendungen abgerufen wird, die die Domäne verwenden (die Benutzeroberfläche und der Webdienst aus meinem obigen Beispiel).

Das ultimative Ziel ist es, Ihren Code so einfach wie möglich zu pflegen.

Als Randnotiz können einige Dinge nicht in eine bestimmte Schicht der Domäne eingeteilt werden (z. B. Protokollierung, Validierung und Autorisierung). Diese Elemente werden üblicherweise als Querschnittsthemen bezeichnet und können in einigen Fällen als eigenständige Ebene behandelt werden, die alle anderen Ebenen sehen und verwenden können.

Persönlich denke ich, dass der mehrschichtige Ansatz veraltet ist und dass der Service-Ansatz besser ist. Sie haben immer noch die klare Linie im Sand, wer was tut, aber es zwingt Sie nicht dazu, so hierarchisch zu sein. Beispielsweise stellen ein Bestellservice, ein Abrechnungsservice und ein Versandservice aus Sicht der Anwendung alle diese Services für Ihre Domain dar, und die oben beschriebene Verschiebung der Verantwortung gilt in diesem Zusammenhang weiterhin. Sie wurde gerade geändert dass Ihre Domain an mehreren Orten existiert, wobei das Konzept der Trennung von Bedenken weiter genutzt wird.

2
Charles Lambert