Świadomość repozytorium DDD dla innych repozytoriów

Question

Czy ogólnie akceptowalne jest, że jedno repozytorium może uzyskać dostęp do innego repozytorium? W szczególności w tym przypadku mam jeden agregat root, który używa innego zagregowanego katalogu głównego, aby określić, które elementy dodać. Opada zgodnie z linią relacji przedmiot/przedmiot. Powodem, dla którego Typ Przedmiotu jest zbiorczym katalogiem głównym, jest to, że można je oddzielnie utrzymywać w narzędziu zarządzania poza zakresem pojedynczego elementu.

Jeśli ma znaczenie, to tworzę tylko instancje repozytorium poprzez implementację fabryki repozytoriów, więc nie jestem bezpośrednio tworzony przez konkretną nazwę klasy. W żadnym momencie suma nie jest świadoma repozytorium.

Edit - Więcej informacji:

Konkretna realizacja jest to, że możemy dołączyć obrazy do dokumentu. Nie tylko możemy zarządzać obrazami na dokumencie, ale są też różne rodzaje obrazów (typy definiowane są jako sposób implementacji, w przeciwieństwie do rozszerzenia). Agregat dokumentów jest jednym z kilku typów innych obiektów w systemie, które wykorzystują te obrazy i nie wszystkie korzystają z tych samych typów. Podczas gdy dołączamy reguły do ​​usług domenowych, jest to bardziej ukierunkowane na tworzenie agregatów dokumentów. Podczas budowania agregatu mamy pięć obrazów określonego typu i po jednym z dwóch pozostałych typów. Wyciągamy je pojedynczo, ponieważ są one przechowywane w osobnych listach w agregacie. Sprawdzanie poprawności nie jest problemem, ale ogranicza rodzaj ocenianych obrazów podczas składania dokumentu.

Answer 1

Myślę, że sprowadza się to do tego, co próbujesz zrobić. Jeśli jest to rodzaj kroku sprawdzania poprawności (np. Usuń wszystkie elementy, które mają typy elementów, które wygasły), możesz argumentować, że należy on do warstwy usługi lub specyfikacji. Z języka, którego używasz (tj. "Określ, które elementy dodać") wydaje się sugerować to ostatnie, choć trudno powiedzieć bez większej ilości szczegółów.

Sądzę, że z pewnego punktu widzenia nie ma prawdziwego powodu, dla którego nie można (w żadnym wypadku nie jestem najczystszym z DDD), zwłaszcza, że ​​przedmiot i jego typ można traktować jako zagregowany pierwiastek i to jest tylko szczegóły implementacji, które należy wprowadzić, aby zapobiec konsoli zarządzania.

Z innego punktu widzenia wydaje się sugerować, że pomiędzy zagregowanymi źródłami pojawia się rozmycie, które może sugerować, że działają dwa różne konteksty. Na przykład można argumentować, że narzędzie do zarządzania tworzy oddzielny, ograniczony kontekst do głównej aplikacji, a zatem przypadek, w którym typ elementu, który jest zbiorczym katalogiem głównym, w rzeczywistości nie ma zastosowania. na przykład Narzędzie do zarządzania może dotyczyć tylko typów elementów (a nigdy elementów), podczas gdy główna aplikacja może wyświetlać typy elementów jako bardziej wartościowe niż obiekt.

Aktualizacja

Jak wspomniałeś montażu dokument ten wydaje się odpowiedzialności klasy fabrycznej, które mogą prawidłowo zmontować ważnego podmiotu (fabryka może użyć typu repozytorium obrazu). Repozytorium powinno (w moich oczach) eksponować kwerendę i dodawanie operacji, a nie logikę do konfigurowania encji (z wyjątkiem może rehydratacji z trwałości).