我有三个必须交互的实体：User，SupportTicket和PhoneConversation。当有人呼叫请求帮助时，用户应该有一个分配给他的SupportTicket，分配给Ticked的PhoneConversation描述呼叫。DDD：在哪里创建实体对象？
我的问题是：在什么单位我应该把方法CreatePhoneSupportTicket()，创建一个新的SupportTicket和PhoneConversation，它们涉及到对方，最后涉及的SupportTicket给用户？
我猜测它不能在用户上，因为这会违反SRP（用户做了更多的事情）。但是该方法本身不止一件事，它应该创建一个PhoneTverset的SupportTicket 和。这是一种情况，当一个服务是一个更好的解决方案，然后把方法放在实体上？谢谢你的帮助！
如果使用新的操作符，如果它符合逻辑的其余部分，则没有任何问题。如果只有一种SupportTicket，则使用new SupportTicket(currentUser)创建一个。或者，如果依赖关系是另一种方式，则向用户添加CreateSupportTicket()方法，并在那里调用new SupportTicket()。 SupportTicket构造函数反过来可以创建一个new PhoneConversation()。如果您稍后决定应该使用某种工厂，则可以随时重构您的代码。但在此之前，您可以想像最简单的解决方案。
硬盘没有你的域成竹在胸地说，但它将使意义有aSupportTicketRepository.CreatePhoneSupportTicket(aUser, aPhoneConversation)
这可能是有意义的一些实体来支持这样的方法，但没有什么阻止你只是在呼叫服务在幕后。
在这种情况下，它看起来像一个分析（你可能已经完成）是为了看看我们知道什么时候。例如，呼叫进入，所以你可以使用呼叫者ID来识别用户。如果你之前见过他，请加载他。如果没有，请创建一个新的。无论哪种情况，您都是以用户身份开始的。
同时，这是一个新的电话，所以创建一个，也许与工厂？
如果它是现有用户，这是现有票证的延续吗？如果是这样，找到它并添加此调用。可能会很方便做点像
Ticket t = user.GetOpenTicket();
t.AddCall(currentCall);
无论如何。但是，对于Ticket.AddCall和user.GetOpenTicket来说，调用服务来完成繁重工作可能是最有意义的。
在这种情况下，我会建议更换把这个方法在Domain Service
所以...域服务是...什么？那么， 如果实体和值对象是我们的域中的“事物” ，则服务 是处理操作和活动的一种方式， 。 逻辑应该直接在实体上吗？ 是的，它确实应该。我们应该是 为我们的实体建模，逻辑 与他们和他们的 子女有关。但有时逻辑 要么不适合实体，要么 它会使实体臃肿和 笨重。那是服务来到 到图片。他们帮助我们将处理多个 实体或处理复杂的 操作或外部 职责的逻辑分割成更适合任务的更适合task.structure的结构 。
我会建议使用一个工厂来创建一个支持票和支持票创作实例中它通电话。