Suppose I am developing a RSS system (following DDD practises). Users have accounts. Accounts have feeds. Feeds have articles.
Article are my aggregate roots as well as
ArticleAccountMeta (an aggregate that contains information whether an account has already read an article).
I decided to go without separate repository model (Hibernate entities), so my aggregate roots are also my ORM entities (for several reasons, not important for the question).
Now let's say a user (account) wants to see all his feeds with their articles. So the server needs to produce a list of feeds with their articles. Alongside each article, I need the
ArticleAccountMeta object to indicate whether the user/account has already read the article. Naturally, I would create a few more "view" classes. These would be returned by a domain service (as the building process is more complicated and contains business logic) and they would directly reference the domain aggregate roots.
My first question is - is it okay to have these view classes in the domain "layer" despite only being a different representation of the already created aggregate roots? Should I call them view models or are they true aggregate roots that are only used for reading?
My second question is - when building DTOs without any additional business logic, is it okay to bypass creating a domain service and use a repository directly?
My third question is - in the domain layer, I don't know how the view classes will be used, thus I should not instruct repositories to fetch specific references eagerly. However, I need to do that to prevent the N+1 problem. What is the correct solution here?