1) Wenn die Anwendung ein Repository verwendet (das ein Infrastrukturdienst ist), wird Repository-Schnittstelle in definiert Domänenebene , während ihre Implementierung in einer Infrastrukturschicht definiert ist, da Domänenmodell auf diese Weise keine ausgehenden Abhängigkeiten aufweist.
a) Wenn wir zu 100% sicher sind, dass ein bestimmter (Nicht-Repository) Infrastrukturdienst InfServ niemals von einem Code in aufgerufen wird Domain-Ebene , dann nehme ich an InfServs -Schnittstelle muss nicht innerhalb einer Domain-Ebene definiert werden?
2) Angenommen, InfServ wird nicht vom Code innerhalb der Domain-Ebene aufgerufen (daher müssen wir die Schnittstelle nicht in Domain-Ebene definieren):
a) Wenn InfServ von Anwendungsschicht-Services aufgerufen wird, nehme ich an, dass Anwendungsschicht implizit von Infrastruktur abhängig sein sollte Schicht und nicht umgekehrt? Mit anderen Worten, sowohl die InfServ -Schnittstelle als auch ihre Implementierung sollten innerhalb einer Infrastruktur-Schicht definiert sein?
b) Und der Grund, warum es für Anwendungsschicht besser ist, eine Abhängigkeit von Infrastrukturebene zu haben und nicht umgekehrt, ist Infrastrukturebene kann von vielen Anwendungen wiederverwendet werden, während Anwendungsschicht in den meisten Fällen nur für eine einzelne Anwendung spezifisch ist und normalerweise nicht von anderen Anwendungen wiederverwendet werden kann?
c) Wenn wir 100% sicher sind, dass kein Code innerhalb Domain-Ebene jemals ein Repository verwenden wird, müssen wir seine Schnittstelle nicht innerhalb von Domänenschicht ?
UPDATE:
1)
Ja, die Definition der Domänenebene kann jedoch auch eine Anwendung enthalten Dienste, die als Fassade über der Domain wirken. Die Anwendung Service bezieht sich normalerweise auf ein Repository und andere Infrastruktur Dienstleistungen. Es orchestriert das Domänenobjekt und die zu implementierenden Dienste Anwendungsfälle.
a)
... die als Fassade über der Domain wirken
Können wir nicht argumentieren, dass "regulär" (die, auf die ich mich in meiner Frage bezogen habe) Anwendungsdienste auch als Fassade über der Domain wirken?
b)
Der Anwendungsdienst verweist normalerweise auf ein Repository und anderes Infrastrukturdienste.
Aus Ihrer Antwort scheint es, als ob Sie vorschlagen (obwohl Sie wahrscheinlich nicht sind), dass "reguläre" Anwendungsdienste normalerweise nicht auf Infrastrukturdienste verweisen , was sie tatsächlich tun (so weit ich weiß)?!
2)
a)
Normalerweise füge ich Anwendungsdienste, wie oben beschrieben, in die Domänenebene.
"Regular" Anwendungsschicht ist auch Teil einer BLL-Schicht, also könnten wir nicht behaupten, dass sie mit Domänenschicht verschmolzen ist (sie sitzt tatsächlich oben auf Domänenebene )?!
b)
Ich halte mich an den hexagonalen Architekturstil ...
Es scheint, dass die hexagonale Architektur nicht das explizite Konzept von Anwendungsschicht (dh von Anwendungsdiensten ) hat?
c)
Teil des Vorteils der Deklaration einer Repository-Schnittstelle in der Domäne Schicht ist, dass es die Datenzugriffsanforderungen der Domäne angibt.
Also sollten wir die Repository-Schnittstelle in die Domain-Ebene aufnehmen, auch wenn wir sie nicht im Domain-Code verwenden?
ZWEITES UPDATE:
2a)
Wenn das, was Sie einen "normalen" Anwendungsdienst nennen, mit dem interagiert Domain, ich denke, es ist akzeptabel, es Teil der Domain zu machen "Schicht". Die Domäne sollte jedoch nicht direkt von der Domäne abhängen umgebenden Anwendungsservice und so ist es möglich, sie aufzuteilen in separate Module, falls gewünscht.
Ich bin mir nicht sicher, ob Sie implizieren, dass das Design von Anwendungsschicht (in der traditionellen Schichtarchitektur) anders ist als beim Zusammenführen von Anwendungsschicht mit Domain-Ebene zum Beispiel mit Onion-Architektur ?
Ich würde sagen, zumindest in Bezug auf Module sollten die beiden nicht anders sein, da wir in beiden Fällen Anwendung und Domänenebene Module? (Obwohl ich gestehen muss, dass ich den Chaper auf Modulen (Evans Buch) übersprungen habe, da ich nicht dachte, dass ich dieses Wissen so früh brauchen würde, um DDD zu lernen: O)
2b)
Ja, weil es mit einer geschichteten Architektur kontrastiert werden kann.Eine strenge layered architecture geliert nicht mit der Idee des Erklärens Repository-Schnittstellen in Domain-Layer und Implementierung in Infrastrukturschicht. Dies liegt daran, dass Sie einerseits eine Abhängigkeit in einer Richtung, aber in Bezug auf die Bereitstellung der Abhängigkeit ist in der anderen. Hexagonal adressiert diese Bedenken, indem es den Domäne in der Mitte. Werfen Sie einen Blick auf die Zwiebelarchitektur - das ist es im Wesentlichen sechseckig aber vielleicht leichter zu fassen.
Ich kenne MVC-Muster oder Asp.Net MVC noch nicht, aber unabhängig davon, aus dem Lesen der ersten drei Teile der Serie (die mich zu dem Punkt verwirrt, den ich nicht mehr lesen wollte), erscheint es:
a) Aus Zwiebel Artikel :
Jede Schicht ist mit den darunter liegenden Schichten verbunden, und jede Schicht ist oft an verschiedene Infrastrukturprobleme gekoppelt.
Der Autor weist darauf hin, dass TLA in einer traditionellen Layered-Architektur Domain-Layer mit Infrastructure-Layern gekoppelt ist, was sicherlich nicht stimmt, da wir normalerweise Infrastruktur definieren Schnittstellen (wie Repository-Schnittstelle ) innerhalb Domain-Ebene ?!
b) Und wenn wir bei der Verwendung von TLA Infrastrukturschnittstellen in Anwendungsschicht definieren, ist auch Anwendungsschicht nicht gekoppelt Infrastrukturebene ?!
c) Ist nicht mit Onion-Architektur eine * Infrastruktur-Schicht * gekoppelt mit Application Core (die Anwendungsschicht enthält), da Infrastruktur-Schnittstellen sind in Application Core definiert?
d) Wenn ja zu c) , ist es nicht besser, Anwendungsschicht auf Infrastrukturebene zu koppeln (aus Gründen, die ich aufgegeben habe) meine ursprüngliche Frage (hier nehme ich an, Domain-Layer wird nicht Infrastructure-Dienste aufrufen))?
4)
Aus Zwiebel Artikel :
Die erste Ebene um das Domänenmodell herum ist normalerweise die Stelle, an der wir es tun würden finde Schnittstellen, die das Objekt speichern und abrufen, Repository-Schnittstellen genannt.
Aus Zwiebel Artikel :
Der Controller hängt nur von den Schnittstellen ab, die in der. definiert sind Anwendungskern. Denken Sie daran, dass alle Abhängigkeiten auf die zentrieren.
Es scheint, dass der Autor andeutet, dass, da Abhängigkeiten nur nach innen gerichtet sind und Infrastruktur-Schnittstellen um das Domänenmodell definiert sind, dieser Code innerhalb des Domänenmodells diese Schnittstellen nicht betreffen sollte. Mit anderen Worten, wir sollten die Repository-Referenz nicht als Argument für eine Methode einer Domain-Entität übergeben (was, wie Sie selbst gesagt haben, erlaubt ist):
%Vor%Aus den oben genannten Gründen muss ich zugeben, dass ich die Vorteile der Verwendung der Onion-Architektur oder sogar der Unterschiede zu TLA (unter der Annahme, dass alle Infrastrukturschnittstellen definiert sind) nicht sehe innerhalb Domänenebene ) - & gt; Mit anderen Worten: Können wir TLA nicht mithilfe des Schemas Onion architecture darstellen?!
ENDGÜLTIGES UPDATE:
2)
b)
Ja. In TLA würde der Domänenlayer direkt kommunizieren Infrastruktur in Bezug auf Klassen, die von der Infrastrukturschicht deklariert werden nicht umgekehrt.
Nur um sicher zu sein - Sie sagen, dass mit TLA eine Infrastruktur-Schnittstelle in Infrastruktur-Ebene definiert würde (ich weiß, dass sie mit Hexagonal- / Onion-Architektur definiert sind im Anwendungskern)?
d)
Die Kopplung geht in beide Richtungen. Der Anwendungskern hängt davon ab Implementierungen in Infrastruktur und Infrastruktur hängen davon ab Schnittstellen im Application Core deklariert.
Mein Punkt ist, dass mit der Onion-Architektur eine InfServ -Schnittstelle innerhalb Anwendungsschicht deklariert wird (hier ist die Annahme, dass InfServ wird niemals von Domain-Ebene aufgerufen. Daher entscheiden wir uns, die InfServ -Schnittstelle nicht innerhalb Domain-Ebene - siehe ursprüngliche 1a -Frage), bedeutet dies, dass Anwendungsschicht die InfServ -Schnittstelle steuert. Aber ich würde argumentieren, dass es besser wäre, wenn Infrastructure layer InfServ -Schnittstelle kontrolliert würde, aus Gründen, die im ursprünglichen 2b Frage ?!
4)
Es scheint, dass der Autor impliziert, dass Abhängigkeiten nur nach innen gerichtet sind und da Infrastrukturschnittstellen um das Domänenmodell herum definiert sind, Der Code innerhalb des Domänenmodells sollte nicht auf diese Schnittstellen verweisen.
Meiner Meinung nach ist Ihr Codebeispiel ein geeigneter Code.
Ich habe also richtig gesagt, dass die Onion Architecture Domain Model nicht Infrastruktur-Interfaces erlaubt, da sie in der Schicht InDe
DDD wird typischerweise in einem sechseckigen / Zwiebel-Baustil präsentiert deshalb kann es etwas Verwirrung geben. Ich denke was du wahrscheinlich hast tun ist bereits sechseckig, weshalb es scheint, als ob es das ist Gleiche Sache.
Ja, ich habe diesen Eindruck auch. Obwohl ich vorhabe, ein wenig tiefer in die Hexagonale Architektur zu schauen (besonders seit das neue DDD-Buch einige Beispiele darauf anlegt), nachdem ich Evans Buch gelesen habe.
VIERTE UPDATE:
2)
d)
Wenn Infrastruktur-eigene Schnittstelle und Implementierung die Domäne ist oder die Anwendungsschicht wäre für die Implementierung der Persistenz verantwortlich für sich selbst.
Ich nehme an, Application oder Domain Schichten müssten es für sich selbst implementieren, da die Referenzierung von Schnittstellen, die in Infrastruktur-Layer definiert sind, die innere Schicht von Onion wäre keine Abhängigkeiten zu äußeren Schichten haben ( Infrastrukturschicht ist die äußere Schicht)?
4)
Das Domänenmodell kann auf Infrastrukturschnittstellen verweisen, z. B. a Repository, weil sie zusammen deklariert sind. Wenn Anwendungsschicht wird von der Domäne wie im Zwischendiagramm und dann von der Domänenebene getrennt kann die Referenzierung von Interfaces vermeiden, da diese in der Anwendungsschicht.
Aber laut diesem Artikel werden Infrastruktur-Interfaces in einem Layer um Domain Layer deklariert, was bedeutet, dass er näher an den äußeren Rändern des Application-Core
danke
1a) Ja, jedoch kann die Definition von Domänenebene Anwendungsdienste umfassen, die über die Domäne als Fassade fungieren. Der Anwendungsdienst verweist normalerweise auf ein Repository und andere Infrastrukturdienste. Es orchestriert Domänenobjekt und die genannten Dienste, um Anwendungsfälle zu implementieren.
2a, b)
Normalerweise füge ich Anwendungsdienste wie oben beschrieben in die Domänenebene ein. Ich neige dazu, mich an die sechseckige Architektur zu halten, auch Ports und Adapter genannt. Die Domäne steht im Mittelpunkt und wird vom Anwendungsdienst gekapselt, und alle externen Verbindungen, einschließlich Repositorys, UI und Dienste, fungieren als Ports.
2c) Der Vorteil der Deklaration einer Repository-Schnittstelle in der Domänenschicht besteht darin, dass sie die Datenzugriffsanforderungen der Domäne angibt.
AKTUALISIERT
1a) Ich hatte nicht vor, dass die Anwendungsdienste, die ich erwähne, von "normalen" Anwendungsdiensten unterschieden werden. Wenn es sich um eine Fassade über der Domain handelt, gelten die Regeln.
1b) Es gibt möglicherweise Dienste, die noch als Anwendungsdienste bezeichnet werden können, aber nicht direkt mit der Domäne verbunden sind, und ich wollte diese ausschließen.
2a) Wenn das, was Sie einen "normalen" Anwendungsdienst nennen, mit der Domäne interagiert, denke ich, dass es akzeptabel ist, sie Teil der Domänen- "Ebene" zu machen. Die Domäne sollte jedoch nicht direkt vom umgebenden Anwendungsdienst abhängig sein. Daher ist es möglich, sie bei Bedarf in separate Module aufzuteilen.
2b) Ja, weil es mit einer geschichteten Architektur kontrastiert werden kann. Eine strikte Schichtarchitektur ist nicht mit der Idee verbunden, Repository-Schnittstellen in der Domänenschicht zu deklarieren und in der Infrastrukturschicht zu implementieren. Dies liegt einerseits daran, dass Sie eine Abhängigkeit in einer Richtung haben, aber in Bezug auf die Bereitstellung ist die Abhängigkeit in der anderen. Hexagonal adressiert diese Bedenken, indem die Domäne in den Mittelpunkt gestellt wird. Werfen Sie einen Blick auf die Zwiebelarchitektur - sie ist im Wesentlichen sechseckig, könnte aber leichter zu verstehen sein.
2c) Ja, aber normalerweise wird die Repository-Schnittstelle von einem Anwendungsdienst referenziert.
UPDATE 2
2a) Sie könnten anders umgesetzt werden, aber die allgemeinen Verantwortlichkeiten sind die gleichen. Der Hauptunterschied besteht im Abhängigkeitsgraphen. Während Sie Anwendungsdienste in ihre eigenen Module mit jeder Architektur trennen können, betont die onion / hexagonale Architektur die Verwendung von Schnittstellen, um Abhängigkeiten von der Infrastruktur zu deklarieren.
2ba) Ja, und das ist in der Tat ein Merkmal der Zwiebelarchitektur.
b) Ja. In TLA würde der Domänen-Layer direkt mit der Infrastruktur in Bezug auf die von der Infrastruktur-Ebene deklarierten Klassen kommunizieren und nicht umgekehrt.
c) Ja, die Infrastruktur implementiert Schnittstellen, die von der Domänenschicht deklariert wurden.
d) Die Kopplung geht in beide Richtungen. Der Anwendungskern hängt von Implementierungen in der Infrastruktur ab, und die Infrastruktur hängt von Schnittstellen ab, die im Anwendungskern deklariert sind.
4) Meiner Meinung nach ist Ihr Codebeispiel ein geeigneter Code. Es gibt Fälle, in denen eine Entität Zugriff auf ein Repository benötigt, um bestimmte Aktionen auszuführen. Um jedoch die Kopplungseigenschaften dieses Codes zu verbessern, wäre es besser, entweder eine spezifische Schnittstelle zu definieren, die die von der Entität benötigte Funktionalität deklariert, oder wenn Lambdas noch besser verfügbar sind. Das Repository könnte dann diese Schnittstelle implementieren und der Anwendungsdienst würde das Repository an die Entität übergeben, wenn das gegebene Verhalten aufgerufen wird. Auf diese Weise ist die Entität nicht von einer allgemeinen Repository-Schnittstelle abhängig, sondern von einer sehr spezifischen Rolle.
DDD wird typischerweise in einem sechseckigen / zwiebelartigen Baustil dargestellt, weshalb es zu Verwirrungen kommen kann. Ich denke, was du wahrscheinlich gemacht hast, ist bereits sechseckig, weshalb es so aussieht, als ob es dasselbe ist.
UPDATE 3
2b) In TLA gäbe es keine oder nicht die gleichen Schnittstellen. Die Domäne würde direkt mit der Infrastruktur kommunizieren, z. B. mit einem Persistenz-Framework, und wäre somit für die Persistenz verantwortlich.
2d) Wenn Infrastruktur-eigene Schnittstelle und Implementierung vorhanden wären, wäre die Domäne oder Anwendungsschicht dafür verantwortlich, Persistenz für sich selbst zu implementieren. In hexagonal / onion ist die Implementierung der Persistenz Teil der Infrastruktur - sie "passt" die abstrakte Domäne an die Datenbank an.
4) Das Domänenmodell kann auf Infrastrukturschnittstellen wie z. B. ein Repository verweisen, da sie zusammen deklariert sind. Wenn die Anwendungsschicht wie im Onion-Diagramm von der Domäne getrennt ist, kann die Domänenschicht die Referenzierung von Schnittstellen vermeiden, da sie in der Anwendungsschicht definiert werden können.
UPDATE 4
2d) Nein, diese Aussage gilt für eine geschichtete Architektur mit einer Hierarchie wie: UI - & gt; Geschäftslogik - & gt; Datenzugriff Die Business-Logik-Schicht hängt von der Datenzugriffsebene ab und muss ihren Datenzugriff basierend auf dem Objektmodell des Datenzugriffs-Frameworks implementieren. Das Datenzugriffs-Framework selbst weiß nichts über Business-Layer.
4) Der Artikel spezifiziert nur eine mögliche Architektur. Es gibt akzeptable Variationen.
Der einzige Vorteil, den ich beim Platzieren von Repository-Schnittstellen in der Anwendungsschicht anstelle der Domäne sehe, ist, wenn Sie die Domänen-DLL in einer anderen Anwendung wiederverwenden möchten, in der Sie die Art und Weise, wie Sie Ihre Sammlungen von Domäneneinheiten abfragen, völlig neu definieren , benötigen völlig andere Repositories.
Es gibt jedoch zwei Haupthindernisse für diesen Ansatz:
Domain-Layer-Dienste. Sie stellen Prozesse dar, die an der Kreuzung vieler Entitäten stehen, und benötigen daher mehrere Referenzen, um ihre Arbeit zu erledigen. Es ist eine übliche und bequeme Sache für sie, diese Referenzen zu bekommen, indem sie Repositories fragen.
Außerdem gibt es spezielle Fälle, in denen einige Entitäten die Hilfe eines Repositorys benötigen, um eine bestimmte andere Entität zu finden. Wenn Sie beispielsweise eine Hierarchie von Aggregatwurzeln mit übergeordneten / untergeordneten Beziehungen zwischen ihnen haben, könnte eine bestimmte Instanz sagen: "Ich brauche die Liste aller meiner Vorfahren / Nachkommen, die diese Kriterien erfüllen". Ein Repository scheint für diese Art von Abfrage am besten geeignet zu sein.
Tags und Links domain-driven-design