Domain Driven Design - Repositories and aggregate roots

Question

I have a domain model that contains a forum.

I have forum, thread and post entities.

The forum is a standalone entity. Ie it does not contain thread as part of an aggregate. This is because threads are not owned by a particular forum (you can move a thread to a different forum).

I don't know if I should model posts as part of a thread aggregate. Posts can't exist without a thread. Delete a thread and you must delete the posts which tells me to make posts part of the thread aggregate.

The only thing is that posts also can be fetched standalone when editing them. Ie when editing a post by it's id.

So I think having a post repository would be good for this purpose, rather than having to fetch the thread, and then fetch the right post via a method on the thread entity.

The only thing with having a separate post repository is that when adding posts, ie addPost(Post), you need to make sure that the thread id has been assigned to the post entity. With an aggregate I guess you would just have the addPost method on the thread entity.

Should I be thinking of bounded contexts? Could I have a post entity and repository, and also have a thread aggregate that also includes post entities?

If I did not go with the thread/post aggregate, how would I handle post deletion when I delete a thread? Should I create a service that calls deleteThread(Thread) on the thread repository, and deletePostsByThreadId(id) on the post repository?

What is the DDD way here?

Answer 1

I'm wondering, if in your case DDD is a good idea. I mean forums are data oriented by nature. Maybe should you consider a simplest approach and just use classic data oriented technologies to query your data. (ie, LINQ, Hibernate, plain SQL, entity framework or whatever you want depending on your plateform)

You program maybe doesn't need a domain layer, or you'll end up with a class ForumDTO which hold data, and Forum which hold business logic, same things for post or thread, to me it seems an anti-pattern.

What do you think ?

Update

I recommend you reading the book from Eric Evans, it has great examples of complex domain where DDD fits really well. After reading this book I was vey enthusiastic to apply what I've learnt, but I've seen that is some case data oriented approach is more appropriate.

To me, there is almost no complex domain logic for a Forum, so you'll endup having a 1<->1 mapping between your data layer and domain layer, it means duplication and overhead as I said.

Seeing the description of your domain, your approach seems data oriented. For example, intuitively a forum HAS threads and threads HAS posts, the domain as you describe it doesn't reflect that, and you seem to normalize your object model to fit your database schema (which will be normalized).

Forum seems the best class to be the Root of the aggregate (it's the more intuitive)

If you really want to use DDD approach, you can inject repositories in your entities, and give your domain object meaningfull name as thread.GetLastPostOf(User user), depending on your requirements.

But I agree with you when you say that you should have a repository with a method GetPostById.