DDD-Repository und Factory
In meiner Anwendung ein paar Schichten. In diesem Thema wird der Schwerpunkt auf Domänen- und Infrastruktur-Ebenen liegen.
Ich habe das Repository-Interface ClientRepositoryInterface im Domain-Layer. Und ich habe die Implementierung dieser Schnittstelle ClientRepositoryImpl in der Infrastruktur-Ebene.
Aber um das Objekt in der Mitte des Zyklus seiner Existenz wiederherzustellen, brauche ich factory (ReconstitutionClientFactory). Rufen Sie die Fabrik wird im Repository sein. Das Buch von Eric Evans wird als eine normale Praxis beschrieben.
Aber wo sollte diese Factory (ReconstitutionClientFactory) liegen? In der Domäne oder in der Infrastruktur-Ebene?
Ich denke in Domain ... ABER! Aber dann ruft die untere Ebene direkt eine höhere Ebene an! Das ist falsch, aber wie richtig?
2 Antworten
Zunächst ist der Schichtenansatz etwas veraltet. Wenn man über Schichten spricht, denkt man an "Kontext", wer oben steht, wer nicht wichtig ist.
Das Repository ist verantwortlich für die Wiederherstellung eines Objekts. Eine Factory erstellt nur ein neues Objekt. Beachten Sie die verschiedenen Semantiken. Das Repository weiß, wie das Speichern / Wiederherstellen in / aus der Persistenz durchgeführt wird und das hängt vom Speicher und der Zugriffsmethode ab.
Also wird alles innerhalb des Repositorys durchgeführt, d. h. in der Infrastruktur. Wenn Sie Dinge serialisieren, dann müssen Sie nur die Deserialisierung zurück (so ist ein Dokument db Dinge sowieso). Wenn Sie ein ORM verwenden oder Dinge in Tabellen speichern, werden Sie alle Abfragen ausführen, die erforderlich sind, um die Daten abzurufen und das Objekt erneut zu füllen. Ein ORM ist der einfachste Weg, da es Reflektion verwenden kann, um private Eigenschaften zu füllen. In diesem Fall ist das ORM selbst die Fabrik.
Eine weitere Sache, die Wiederherstellung, während dies technisch von einer Domänenfactory ausgeführt werden kann, ist nicht der Zweck der Factory, da dies die Ebenengrenzen bricht. Wir wollen alles Persistenz in der Infrastruktur halten.
Fabrik & amp; Repository-Konzepte
Um Ihre Frage zu beantworten, ist es wichtig, sich auf Verantwortlichkeiten der von DDD definierten Konzepte zu konzentrieren.
Im blauen Buch gibt es einen Abschnitt, der sich mit dem Problem beschäftigt, das Sie beschreiben:
Eine FACTORY behandelt den Anfang des Lebens eines Objekts; Ein REPOSITORY hilft, die Mitte und das Ende zu verwalten.
und speziell für Ihre Frage:
Da das REPOSITORY in diesem Fall Objekte basierend auf Daten erstellt, betrachten viele Leute das REPOSITORY als eine FACTORY - tatsächlich ist es aus technischer Sicht.
(beide Zitate von Evans, Kapitel 6, Abschnitt "Die Beziehung zu Fabriken")
Um die Konzepte rein zu halten, ist es wichtig, dass die Schnittstelle Ihrer Fabriken und Repositories sauber ist. Erlauben Sie also nicht, neue Geschäftsobjekte über die Repository-Schnittstelle zu erstellen, und erlauben Sie nicht, vorhandene über die Factory-Schnittstelle abzufragen.
Wenn Sie die Schnittstellen sauber halten, bedeutet dies jedoch nicht, dass Sie keine Factory aus der Repository-Implementierung verwenden sollten, da das Repository schließlich eine Instanz erstellt und wenn diese Instanz erstellt wird komplex, eine Fabrik ist die passende Lösung.
Um Evans noch einmal zu zitieren:
Wann immer es Komplexität gibt, ein Objekt von einem anderen Medium wiederherzustellen, ist die FACTORY eine gute Option.
Beachten Sie jedoch, dass das Repository höchstwahrscheinlich eine andere Methode in der Factory aufruft als die Clients, die wirklich ein neues Domänenobjekt erstellen möchten (im Gegensatz zur Wiederherstellung).
Es gibt sogar ein Beispiel in Evans 'Buch, das den Ansatz veranschaulicht:
Beantworte deine Frage
Nachdem klar ist, dass dies erlaubt ist, können wir uns nun auf Ihre Frage konzentrieren, wo Sie die Fabrik ablegen sollten:
Die DDD-Factory-Schnittstelle gehört in die Domäne, da Ihre Domänenlogik dies zum Erstellen von Domänenobjekten verwendet.
Die DDD-Wiederherstellungs-Factory-Schnittstelle gehört nicht in die Domäne, da dies nur für Ihr Repository relevant ist. Es existiert nicht in der realen Welt Ihrer Domain.
Wenn Sie nun eine Architektur verwenden, die Abhängigkeiten von der Domäne zur Infrastruktur verhindert (was Sie wahrscheinlich beim Anwenden von DDD tun sollten), ist es klar, dass die Factory-Implementierung in die Infrastruktur gehört. Beachten Sie, dass es egal ist, ob Sie Ihre Layer Layer, Ringe, Realms oder was auch immer aufrufen, die Abhängigkeiten sind der wichtige Teil.
Tags und Links repository-pattern factory-pattern domain-driven-design ddd-repositories