Suppose I am developing a RSS system (following DDD practises). Users have accounts. Accounts have feeds. Feeds have articles. Account
, Feed
and 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?