我有三個必須交互的實體：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的結構 。
我會建議使用一個工廠來創建一個支持票和支持票創作實例中它通電話。