title: Domain Driven Design - Repositories and aggregate roots
body: <p>I have a domain model that contains a forum.</p>
  
  <p>I have forum, thread and post entities. </p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>The only thing is that posts also can be fetched standalone when editing them. Ie when editing a post by it's id.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>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?</p>
  
  <p>What is the DDD way here?</p>