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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

С Пошаговое проектирование в домене (бесплатная электронная книга) Страница # 19

Answer 4

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

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

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

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

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

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

Answer 5

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