I am using a DDD-like approach for a greenfield module of an existing application; it's not 100% DDD due to architecture but I'm trying to use some DDD concepts. I have a bounded context (I think that's the proper term - I'm still learning about DDD) consisting of two Entities:
Message. Conversation is the root, as a Message doesn't exist without the conversation, and all messages in the system are part of a conversation.
I have a
ConversationRepository class (although it's really more like a Gateway, I use the term "Repository") which finds Conversations in the database; when it finds a Conversation it also creates (via Factories) a list of messages for that Conversation (exposed as a property). This seems to be the correct way of handling things as there doesn't seem to be a need for a full-blown
MessageRepository class as it only exists when a Conversation is retrieved.
However, when it comes to saving a Message, is this the responsibility of the ConversationRepository, since it's the aggregate root of Message? What I mean is, should I have a method on ConversationRepository called, say,
AddMessage that takes a Message as it's parameter and saves it to the database? Or should I have a separate repository for finding/saving Messages? The logical thing seems to be one repository per Entity, but I've also heard "One repository per Context".