Die Anwendungsschicht befindet sich irgendwo zwischen der Domänenebene und der Präsentationsschicht. Der Controller ist Teil der Präsentationsschicht und sendet Befehle oder Abfragen an die Anwendungsschicht, auf der die Anwendungsdienste sie mithilfe der Dienste und Objekte des Domänenmodells ausführen. So unterscheiden sich die Controller von den Anwendungsdiensten, und sie sind wahrscheinlich an das tatsächliche Kommunikationsformular gebunden, z. HTTP. Sie sollten Domänen-Services nicht direkt von Controllern aus aufrufen. Dies könnte ein Zeichen für falsch platzierten Code sein.
Domain Driven Design: Domain Service, Application Service
- Domain Services: Fasst Business-Logik, die nicht natürlich innerhalb einer Domäne Objekt passt, und sind nicht typisch CRUD-Operationen - zu einem Repository gehören jene würden.
- Anwendungsdienste: Wird von externen Benutzern verwendet, um mit Ihrem System zu sprechen (denken Sie an Webdienste). Wenn Verbraucher Zugriff auf CRUD Operationen benötigen, würden sie hier ausgesetzt werden.
So ist Ihr Service wahrscheinlich ein Application Service und kein Domain-Service, oder ein Teil App Services, Service einige Teilfläche. Sie sollten Ihren Code überprüfen und umgestalten. Ich denke, nach 4 Jahren ist das egal, aber ich hatte die gleichen Gedanken bei einer Anwendung, die ich gerade entwickle. Diese App ist möglicherweise zu klein, um DDD darauf zu verwenden. Verwirrende Controller mit App-Services sind hier ein Zeichen für Overengineering.
Es ist eine interessante Frage, wenn Sie beginnen, weitere Schichten hinzuzufügen. Ich denke, jede App sollte mit einer Art von domain model and adapters starten, um eine Verbindung zu diesem Domänenmodell herzustellen. Wenn die App einfach genug ist, ist das Hinzufügen von mehr als zwei Ebenen möglicherweise nicht notwendig. Aber das ist nur ein Gedanke, ich bin nicht so erfahren mit DDD.
Der Controller bedient Anfragen von der Ansicht, indem er die Anfrage - oder den relevanten Teil davon - an das Model weiterleitet. MVC ist eine Architektur und könnte definitiv sowohl auf Winforms als auch auf Web-Apps angewendet werden. Ich möchte mich hinsichtlich der Position des Controllers unterscheiden. Die View ist definitiv die einzige UI-Ebene und der Sinn von MVC besteht darin, diese UI-Ebene vom Controller getrennt zu halten. Dein Punkt ist aber gut gemacht; Danke für die Antwort. – Louis
-1. Controller sind Anfragen/Kommandokoordinatoren.In einer hexagonalen Architektur befinden sich Controller oberhalb von Anwendungsdiensten/Kommando-Handlern/Query-Handlern. Controller ist ein Anforderungsübersetzer und ist mit dem Kommunikationsprotokoll (obere Schicht) und den Befehls-/Abfrage-Handlern (Anwendungsdienste von einer niedrigeren Ebene) gekoppelt. Controller können als Anwendungsdienst-Fassaden betrachtet werden, da sie den Befehl/die Abfrage/die Nachricht, die von den unteren Ebenen (Anwendungsdienst-/Befehlsabfrage-Handler) verarbeitet werden sollen, übersetzen und vorbereiten. – Tudor
-1 weil Controller nichts mit DDD zu tun haben. Es ist irrelevant, wo Sie die Controller setzen, könnten Sie sagen, die Controller sind nur Nachrichten/Kommunikation Koordinatoren und sie sind in beide Richtungen gekoppelt: ui und Application Service. Sie könnten Controller in einem beschränkten Kontext haben, in dem es keine Benutzeroberfläche gibt (ein reiner Befehlskontext). Und Sie könnten einen beschränkten Kontext nur für die Präsentation haben (eine zusammengesetzte Geschäftskomponente, die nur für die Abfrage von 2 oder mehr beschränkten Kontexten erstellt wurde). P.S. Controller haben eine geringe Kopplung an die Benutzeroberfläche, sie erwarten nur eine Reihe von Anforderungsparametern, egal von wo. – Tudor