I am developing an RESTish web service. I think I got the idea of the difference between aggregation and composition. Aggregation does not enforce lifecycle/scope on the objects it references. Composition does enforce lifecycle/scope on the objects it contain/own.
If I delete a composite object then all the objects it contain/own are deleted as well, while the deleting an aggregate root does not delete referenced objects.
1)
If it is true that deleting aggregate roots does not necessary delete referenced objects, what sense does it make to not have a repository for the references objects? Or are aggregate roots as a term referring to what is known as composite object?
2)
When you create an web service you will have multiple endpoints, in my case I have one entity Book and another named Comment. It does not make sense to leave the comments in my application if the book is deleted. Therefore, book is a composite object. I guess I should not have a repository for comments since that would break the enforcement of lifecycle and rules that the book class may have. However I have URL such as (examples only):
GET /books/1/comments
POST /books/1/comments
Now, if I do not have a repository for comments, does that mean I have to load the book object and then return the referenced comments? Am I allowed to return a list of Comment entities from the BookRepository, does that make sense? The repository for Book may eventually become rather big with all sorts of methods. Am I allowed to write JPQL (JPA queries) that targets comments and not books inside the repository? What about pagination and filtering of comments. When adding a new comment triggered by the POST endpoint, do you need to load the book, add the comment to the book, and then update the whole book object?
What I am currently doing is having a own CommentRepository, even though the comments are deleted with the book. I could need some direction on how to do it correct. Since you are exposing not only root objects in RESTish services I wonder how to handle this at the backend.
I am using Hibernate and Spring.
1
You have no other choice than to query comments by book id when you are dealing with RDBMS. For document database it is a different story and this is why document databases are more suitable for DDD than RDBMSes.
Just remember, I am repeating this again, DDD is not about repositories and any other particular implementation that Eric Evans has mentioned in his book. If you ever talk to him, you will learn that he sometimes regrets that there were so many implementation details included in the book. People think too much about repositories and specifications than on actual domains… Unless your application has a huge multi-domain landscape, nothing stops you from issuing queries like session.Query.Where(c => c.BookId == myBookId) right in your REST service. Your service is already a service layer, one more abstraction will be an overkill. You already mentioned that repositories grow and I bet most of your repository methods are one line data access calls. No domain expert will say this is right.