DDD: Где создавать объекты сущностей?

Question

У меня есть три объекта, которые должны взаимодействовать: User, SupportTicket и PhoneConversation. Когда кто-то звонит с просьбой о помощи, у Пользователя должен быть назначенный ему SupportTicket, а PhoneConversation назначен для Ticked, описывающего вызов.

Мой вопрос: В какой сущности я должен поставить метод CreatePhoneSupportTicket(), который создает новый SupportTicket и PhoneConversation, связывает их друг с другом и, наконец, относится к SupportTicket Пользователю?

Я предполагаю, что это не может быть на пользователе, потому что это нарушит SRP (пользователь делает еще несколько вещей). Но сам метод делает больше, чем один, он должен создать как SupportTicket , так и PhoneConversation. Является ли это ситуацией, когда служба является лучшим решением, а затем устанавливает методы для сущностей? Спасибо за вашу помощь!

Answer 1

Нет ничего плохого в использовании нового оператора, если он соответствует остальной части вашей логики. Если есть только один вид SupportTicket, используйте new SupportTicket(currentUser), чтобы создать его. Или, если зависимость является другим способом, добавьте метод CreateSupportTicket() для пользователя и вызовите new SupportTicket(). Конструктор SupportTicket, в свою очередь, может создать new PhoneConversation(). Если позже вы решите использовать какой-либо завод, вы всегда можете реорганизовать свой код. Но до тех пор пройдите самое простое решение, которое вы можете себе представить.

Answer 2

Трудно сказать, без глубокого знания своего домена, но будет ли смысл иметь aSupportTicketRepository.CreatePhoneSupportTicket(aUser, aPhoneConversation)

Answer 3

Это может иметь смысл для некоторых лиц, чтобы поддержать такие методы, как это, но ничего не мешает вам просто вызов службы за кулисами.

В этом случае, похоже, что анализ (который вы, наверное, уже сделали), предназначен для того, чтобы узнать, что мы знаем и когда. Например, вызов приходит, поэтому вы, вероятно, можете использовать идентификатор вызывающего абонента для ID пользователя. Если вы видели его раньше, загрузите его. Если нет, создайте новый. В любом случае вы начинаете с пользователя.

В то же время, это новый звонок, поэтому создайте его, возможно, с завода?

Если это уже существующий пользователь, является ли это продолжением существующего билета? Если да, найдите и добавьте этот вызов. Возможно, будет удобно делать что-то вроде

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

Неважно. Но это, вероятно, имеет наибольший смысл для Ticket.AddCall и user.GetOpenTicket вызывать услуги для тяжелого подъема.

Answer 4

В этом случае я буду рекомендовать поставить этот метод в Domain Service

Итак ... Доменные службы Are ... Что? Ну, , если объекты и объекты ценности - это «вещи» в нашем домене, услуги - это способ совершения действий, операции и действия. Не должно Логика Быть на объектах прямо? Да, это действительно так. Мы должны быть , моделируя наши объекты с логикой , которая относится к ним и их детям . Но иногда эта логика либо не помещается на Entity, либо , это создало бы раздутый объект и .То есть, когда услуги приходят . Они помогают нам разделить логику, которая имеет дело с несколькими объектами или занимается сложными операциями или внешними функциями, в отдельной структуре , более подходящей для задачи. Структура больше подходит для задачи.

От Domain Driven Design Step by Step (Free E-book) Страница № 19

Answer 5

Я хотел бы предложить использовать завод, чтобы создать техподдержки и создание системы поддержки билет конкретизирует телефонный разговор внутри него.