During my draft project I'm wondering about DDD Aggregate Root and its Entities. Let's say that my aggregate is Ticket model and it contain entities of its Replies. How should I menage my Replies? Every examples shows that I should manage Replies directly from Aggregate like that:
$ticket->updateReply(...);
But What I would really like to do is:
$ticket->getReply(id)->update(...)
Or more:
$ticket->getReplies()->get(id)->update(...)
My aggregate Api is more than readable but logic looks little outside the Aggregate. Is my thinking wrong? Or its really bad practice?
$ticket->updateReply(id, ...);
How the actual reply is retrieved and updated is hidden behind the ticket abstraction; that means, among other things, that if you are ever tempted to change how you have implemented the reply structure, you only need to change the code in one place (within the implementation of Ticket). Everything else just talks to the API.
$ticket->getReplies()->get(id)->update(...)
This is a classic anti pattern; the consumer needs to know more about Ticket, rather than less, and therefore changing the implementation of Ticket is harder rather than easier.
Furthermore, because you are allowing the consumer to update the replies directly, you preclude Ticket from protecting the replies structure; any validation/consistency checks now need to be implemented by every consumer, rather than in once place.
As a design consideration: the fact that you want to reach through Ticket to get to replies may be trying to tell you that Reply should be a separate aggregate from Ticket. The fact that the Reply entity and the Ticket entity have a relation that joins them doesn't imply that they must be part of the same Aggregate.