DDD: Где создать объекты объекта?
У меня есть три объекта, которые должны взаимодействовать: User, SupportTicketи PhoneConversation. Когда кто-то звонит в запрос справки, Пользователю нужно присвоить SupportTicket ему с PhoneConversation, присвоенным Отмеченному описанию вызова.
Мой вопрос: В том, какой объект должен я помещать метод CreatePhoneSupportTicket() это создает новый SupportTicket и PhoneConversation, связывает их друг с другом и наконец связывает SupportTicket с Пользователем?
Я предполагаю, что это не может быть на пользователе, потому что это нарушило бы SRP (пользователь делает еще несколько вещей). Но сам метод делает больше чем одну вещь, он должен создать и SupportTicket и PhoneConversation. Действительно ли это - ситуация, когда Сервис является лучшим решением, затем помещая методы на объекты?Спасибо за помощь!
4 ответа
Нет ничего плохого в использовании оператора new, если он подходит к остальной части вашей логики. Если существует только один вид SupportTicket, используйте new SupportTicket(currentUser) для его создания. Или, если зависимость обратная, добавьте метод CreateSupportTicket() к User и вызывайте new SupportTicket() там. Конструктор SupportTicket, в свою очередь, может создать new PhoneConversation(). Если позже вы решите, что следовало использовать какую-то фабрику, вы всегда сможете рефакторить свой код. Но до тех пор выбирайте самое простое решение, которое только можно представить.
Некоторым объектам может быть целесообразно поддерживать подобные методы, но ничто не мешает вам просто вызвать службу за кулисами.
В этом случае кажется, что анализ (который вы, вероятно, уже сделали) предназначен для того, чтобы увидеть, что мы знаем и когда. Например, поступает вызов, поэтому вы, вероятно, можете использовать идентификатор вызывающего абонента для идентификации пользователя. Если вы видели его раньше, загрузите его. Если нет, создайте новый. В любом случае вы начинаете с пользователя.
В то же время это новый вызов, поэтому создайте его, возможно, с помощью фабрики?
Если это существующий пользователь, является ли это продолжением существующей заявки? Если да, найдите его и добавьте этот вызов. Может быть удобно сделать что-нибудь вроде
Ticket t = user.GetOpenTicket();
t.AddCall(currentCall);
Как угодно. Но, вероятно, наиболее целесообразно использовать вызовы Ticket.AddCall и user.GetOpenTicket в службы для выполнения тяжелой работы.
Трудно сказать без глубокого знания вашего домена, но будет ли иметь смысл aSupportTicketRepository. CreatePhoneSupportTicket(aUser, aPhoneConversation)
В этом случае я рекомендую поместить этот метод в Доменную службу
Итак... Доменные службы ... Что? Колодец если сущности и объекты значений являются «вещи» в нашем Домене, Услуги являются способом борьбы с действиями, операции и мероприятия. Не Логика Быть на сущностях напрямую? Да, так и должно быть. Мы должны быть моделирование наших Сущностей с помощью логики что относится к ним и их дети. Но иногда эта логика либо не помещается на Сущность,или это приведет к раздуванию Сущности и громоздкий. Именно тогда приходят Сервисы в картину. Они помогают нам разделиться логика, имея дело с несколькими Сущности, или которые имеют дело со сложными операции или внешние обязанности, в отдельные структура больше подходит для задачи.структура больше подходит для задачи.
Из Domain Driven Design Step by Step (Бесплатная электронная книга) Страница #19