The idea of an aggregate is to guarantee consistency, being the root responsible for data integrity and forcing invariants.
Suppose there's a rule like "The fabric of all seats must be the same", or ""you can only spill coffee on the seat if there's someone inside the car". It will be much harder to enforce these, once the clients will be able to change the fabric separately, or these invariants will need to be forced outside (danger zone).
IMHO, if integrity or forcing invariants is not an issue, then aggregates are not really needed. But, if it is necessary, my advice is to start everything with the car. But always think of the model. If there are invariants like these, then who enforces these invariants? Then try passing this idea to the code, and everything should be fine.
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.
Best Answer
I don't know enough to "know," but it sounds good to me - besides, who is "in charge" of determining such things? This industry is so full of subjectivity when it comes to buzzwords and the application thereof to a given implementation.
For me, the most important core principle of DDD is whether or not you have kept the application true to the perspective of the business people and follows the ubiquitous language as closely as possible. I can't tell that from your description, but you should be able to make that judgment well enough.
Don't get too caught up in "perfection," just the fact that you are attempting to use DDD is admirable, and if you are doing it as best you know how given the knowledge about it that you posses, I don't see why it would be an invalid approach.
Obviously, there will be those that disagree, but I wouldn't be too hard on yourself. As long as you can look back at this implementation in a month or two and see where it could've been done better, you are probably just fine. :)