Ich habe Probleme, eine klare Linie zwischen Präsentations- und Anwendungsschicht in Domain Driven Design zu ziehen.
Wohin sollen Controller, Ansichten, Layouts, Javascript- und CSS-Dateien gehen?
Befindet es sich in der Anwendung oder in der Präsentationsschicht?
Und wenn sie alle zusammen in derselben Schicht liegen, was enthält die andere? Ist es leer
Antworten:
Nur weil jemand "Application Layer" und "Presentation Layer" erstellt und benannt hat, heißt das nicht, dass Ihre Anwendung sie haben sollte. Sie sollten Ebenen erstellen, nachdem Sie eine erhebliche Menge an Code erstellt haben, den Sie zusammen gruppiert haben, und diese Gruppe aus Gründen der Kommunikation zwischen Entwicklern und der Klarheit des Codes benennen möchten.
Ab DDD. Die Anwendungsschicht ist alles, was keine Domänenschicht ist. Dazu gehören Anwendungslogik, Präsentations- und Anwendungsdienste.
Aus DDD-Sicht gibt es einen großen Unterschied zwischen der Anwendungsschicht und der Präsentationsschicht.
Obwohl sich DDD darauf konzentriert, wie die Domäne mithilfe der DDD-Bausteine und -Konzepte wie begrenzte Kontexte, allgegenwärtige Sprache usw. modelliert wird, ist es dennoch wichtig, die verschiedenen Ebenen in Ihrer App klar zu identifizieren und zu trennen.
Die Architektur spielt eine große Rolle bei der Implementierung einer erfolgreichen DDD-App. Eine berühmte Architektur, die in letzter Zeit viel Aufsehen erregt hat, ist die Zwiebelarchitektur:
In diesem Design sind die UI / Präsentationsschicht und die Anwendungsschicht klar voneinander getrennt. Das Zusammenführen der beiden führt zu einer engen Kopplung zwischen zwei Schichten, die klare getrennte Bedenken und Verantwortlichkeiten haben.
Die Präsentationsebene sollte nur die Präsentationslogik enthalten. Vermeiden Sie intelligente Benutzeroberflächen, die zu viel wissen. Hier befinden sich neben CSS, JS, Vorlagen, Formularen und allem, was sich auf Antwort- und Anforderungsobjekte bezieht, hauptsächlich die Controller und Ansichten der MVC.
Die durch die Präsentation ausgegebenen Aktionen werden über Befehle an die Anwendungsschicht delegiert. Die Anwendungsschicht enthält die Anwendungslogik. Normalerweise wird es einem Anwendungsfall zugeordnet. Es enthält, WAS das System tun sollte, um einen Anwendungsfall zu erfüllen. Ein typischer Anwendungsdienst fordert ein Repository auf, ein Aggregat zurückzugeben, und ruft dann eine Aktion für dieses Aggregat auf.
Schauen Sie sich das Beispielprojekt von Vaughn Vernons IDDD an
entry pointund composition rootplatziert? Ich dachte immer, es sei eine Verantwortung der ApplicationSchicht. Aber jetzt sieht es so aus, als wäre dies eine PresentationSchicht.
Domain Driven Design hat weder mit der Präsentationsschicht noch mit der Anwendungsschicht etwas zu tun. DDD ist eine Methode, deren Hauptaugenmerk auf der Domänenschicht liegt. Das heißt, DDD legt keine Einschränkungen in Bezug auf eine andere Ebene außer der Domänenebene fest, und Ihre Frage könnte auch im Kontext einer anderen Methodik gestellt werden.
Abgesehen davon ist es sehr üblich, eine vierschichtige Architektur für DDD-Anwendungen zu verwenden. Hier ist ein Beispiel für eine solche Anwendung, die die Ebenen und ihre beabsichtigte Verwendung zeigt: DDDSample Architecture . Wenn Sie diese Architektur verwenden, werden Ihre Ansichten und Layouts auf die Ebene "Schnittstellen" und die Controller, sofern sie von der Schnittstelle unabhängig sind, auf die Ebene "Anwendung" verschoben.
Sie können auch eine andere Art von Architektur wählen, da DDD keine Einschränkungen auferlegt. Es gibt viele MVC-Frameworks, die unterschiedliche Strukturen haben und dennoch auch für DDD-Anwendungen verwendet werden können. Dann würden Sie natürlich Ihre Ansichten und Layouts entsprechend platzieren.