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