DDD: Where to create entity objects?

Question

I have three entities that must interact: User, SupportTicketand PhoneConversation. When someone calls in requesting help, the User should have a SupportTicket assigned to him, with a PhoneConversation assigned to the Ticked describing the call.

My question is: In what entity should I put the method CreatePhoneSupportTicket() that creates a new SupportTicket and a PhoneConversation, relates them to each other and finally relates the SupportTicket to the User?

I'm guessing it can't be on the user because that would violate the SRP (the user does a few more things). But the method itself does more than one thing, it should create both a SupportTicket and a PhoneConversation. Is this a situation when a Service is a better solution then putting methods on entities? Thanks for your help!

Answer 1

Hard to say without an intimate knowledge of your domain, but would it make sense to have aSupportTicketRepository.CreatePhoneSupportTicket(aUser, aPhoneConversation)

Answer 2

It might make sense for some entities to support methods like this, but there's nothing preventing you from just calling a service behind the scenes.

In this case, it seems like an analysis (that you've probably already done) is in order to see what we know and when. For example, the call comes in so you can probably use caller-ID to ID the user. If you've seen him before, load him. If not, create a new one. In either case, you're starting with a user.

At the same time, this is a new call, so create one, perhaps with a factory?

If it's an existing user, is this a continuation of an existing ticket? If so, find it and add this call. Might be convenient to do somethign like

Ticket t = user.GetOpenTicket();
t.AddCall(currentCall);

Whatever. But it probably makes the most sense for Ticket.AddCall and user.GetOpenTicket call into services to do the heavy lifting.

Answer 3

There's nothing wrong with using the new operator if it fits the rest of your logic. If there is only one kind of SupportTicket, use new SupportTicket(currentUser) to create one. Or, if the dependency is the other way, add a CreateSupportTicket() method to User and call new SupportTicket() there. The SupportTicket constructor in turn can create a new PhoneConversation(). If you decide later that you should have used some kind of factory, you can always refactor your code. But until then, go for the simplest solution you can imagine.

Answer 4

In this case i will recomend putting this method in a Domain Service

So … Domain Services Are … What? Well, if Entities and Value Objects are the “things” in our Domain, the Services are a way of dealing with actions, operations and activities. Shouldn’t Logic Be on the Entities Directly? Yes, it really should. We should be modelling our Entities with the logic that relates to them and their children. But sometimes that logic either doesn’t fit on the Entity, or it would make the Entity bloated and unwieldy. That is when Services come into the picture. They help us split logic that deals with multiple Entities, or that deals with complex operations or external responsibilities, into a separate structure more suited to the task.structure more suited to the task.

From Domain Driven Design Step by Step (Free E-book) Page #19