@MarcelMcOne: Okej, tak też można zrobić, mam repozytoria do każdego korzenia agregatu. Jednak myślałem nad wydzieleniem tego, ponieważ wtedy repozytoria domeny będą zwracać obiekty domenowe oraz DTO które są utworzone na podstawie 2 korzeni. Widziałem jeszcze podejście które wymaga utworzenie osobnego "read" projektu/projektów które mają osobne repozytoria tylko do zapytań.

@MarcelMcOne: No właśnie tu się pojawia moje pytanie, nie wiem w którym miejscu to umieścić zgodnie ze sztuką. Dto poprostu bym tworzył odrazu z wyniku zapytania. Tylko czy robić to w jakimś repozytorium które pozwala mi tylko odczytywać dane, czy w środku query ? Wiem że w kwestii implementacji jest to tak naprawdę bez różnicy, ciekawi mnie jak to widzą bardziej doświadczeni programiści.

@MarcelMcOne: Jest to podejście zgodne z DDD, ale w moim przypadku potrzebuje danych z 2 powiązanych korzeni. Załóżmy że zwracam obiekt domenowy z repozytorium, posiada on swoje dzieci oraz dane, a także id powiązanego całkiem osobnego aggregate roota. Jednak aby uzyskać dane z tego powiązanego obiektu potrzebowałbym wywołać jego własne repozytorium, wtedy miałbym już wszystkie dane i mógłbym skomponować z tego ładne dto. Zastanawia mnie jednak to że wtedy wykonujePokaż całość

@MQs: Rozumiem przez to że tylko aggregate roots powinny mieć repozytoria, dostęp do dzieci powinien być tylko poprzez aggregate root, a nie poprzez repozytoria.

@lukpep
@alex-fortune
@MQs dzięki wielkie wam za odpowiedzi, będę szedł w stronę stworzenia modeli które posłużą mi tylko do odczytu, oraz nie ruszania obiektów domenowych przy query. Chociaż myślę że to nie ostatni raz kiedy DDD zmusi mnie nad porządnym przemyśleniem architektury oraz implementacji.