DDD-Repository-Kenntnis anderer Repositories

Question

Ist es allgemein akzeptabel, dass ein Repository auf ein anderes Repository zugreifen kann? Speziell in diesem Fall habe ich einen Aggregatstamm, der einen anderen Aggregatstamm verwendet, um zu bestimmen, welche Entitäten hinzugefügt werden sollen. Es fällt in die Richtung einer Item/Item Type-Beziehung. Der Grund dafür, dass es sich bei dem Elementtyp um ein Sammelstammelement handelt, liegt darin, dass sie separat innerhalb eines Verwaltungstools außerhalb des Bereichs eines einzelnen Elements verwaltet werden können.

Wenn es nicht egal, ich schaff' nur meine Repository-Instanzen über eine Repository Fabrik Implementierung, so dass ich nicht direkt durch die konkreten Klassennamen zu schaffen. Zu keinem Zeitpunkt ist dem Aggregat das Repository bekannt.

bearbeiten - Weitere Informationen:

Die spezifische Implementierung ist, dass wir Bilder auf ein Dokument anhängen. Wir können nicht nur die Bilder auf dem Dokument verwalten, sondern auch verschiedene Arten von Bildern (Typen, die beispielsweise so definiert sind, wie sie implementiert sind, im Gegensatz zu einer Erweiterung). Das Dokumentenaggregat ist einer von wenigen anderen Objekten im System, die diese Bilder verwenden, und sie verwenden nicht alle die gleichen Typen. Während wir in den Domänendiensten Regeln anhängen, ist dies speziell darauf ausgerichtet, das Dokumentenaggregat zu erstellen. Beim Erstellen des Aggregats haben wir fünf Bilder eines bestimmten Typs und jeweils eines von zwei anderen Typen. Wir ziehen diese einzeln, weil sie in separaten Listen im Aggregat gespeichert sind. Die Validierung ist nicht das Problem, sondern begrenzt, welche Art von Bildern beim Zusammenstellen des Dokuments ausgewertet wird.

Answer 1

Ich denke, es läuft darauf hinaus, was Sie versuchen zu tun. Wenn es sich um eine Art von Validierungsschritt handelt (z. B. um alle Elemente zu entfernen, deren Elementtypen abgelaufen sind), könnten Sie argumentieren, dass sie zu einer Serviceschicht oder Spezifikation gehören. Aus der Sprache, die Sie verwenden (d. H. "Bestimmen, welche Entitäten hinzugefügt werden sollen"), scheint es Letzteres zu empfehlen, obwohl es ohne weitere Details schwer zu sagen ist.

Ich denke, aus einem bestimmten Blickwinkel gibt es keinen wirklichen Grund, warum Sie nicht (ich bin keineswegs eine super DDD reinsten), vor allem da ein Item und seine Art als eine aggregierte Wurzel angesehen werden kann und es ist Nur das Implementierungsdetail, das Sie bereitstellen müssen, um eine Verwaltungskonsole zu verhindern.

Von einem anderen Standpunkt aus scheint es, zu zeigen, dass eine Unschärfe zwischen Aggregate Wurzeln gibt es die zwei unterschiedliche Kontexte sind bei der Arbeit vorschlagen könnte. Zum Beispiel könnte man argumentieren, dass ein Management-Tool einen separaten begrenzten Kontext zu Ihrer Hauptanwendung bildet und daher der Fall, dass der Elementtyp ein aggregierter Root ist, nicht wirklich zutrifft. z.B. Das Verwaltungstool befasst sich möglicherweise nur mit Elementtypen (und niemals mit Elementen), während Ihre Hauptanwendung Elementtypen mehr als ein Wertobjekt als eine Entität betrachtet.

aktualisieren

Wie Sie das Dokument erwähnt Zusammenbauen dies wie der Verantwortung eines Factory-Klasse scheint, die korrekt eine gültige Einheit zusammenstellen können (kann das Werk, das Repository Bildtyp verwenden). Ein Repository sollte (in meinen Augen) die Abfrage und das Hinzufügen von Operationen offen legen, nicht die Logik zum Konfigurieren von Entitäten (außer vielleicht, dass es von Persistenz rehydratisiert).