Управление агрегатными объектами (DDD)
Во время моего чернового проекта мне интересно узнать о DDD Aggregate Root и его объектах. Скажем, мой агрегат - это модель Ticket, и она содержит объекты своих ответов. Как мне управлять своими ответами? Каждый пример показывает, что я должен управлять ответами прямо из Aggregate следующим образом:
$ticket->updateReply(...);
Но что мне действительно хотелось бы сделать, так это:
$ticket->getReply(id)->update(...)
Или больше:
$ticket->getReplies()->get(id)->update(...)
Мой агрегированный API более чем удобочитаем, но логика мало выглядит вне агрегата. Я ошибаюсь? Или это действительно плохая практика?
Ответы 1
$ticket->updateReply(id, ...);
Способ получения и обновления фактического ответа скрыт за абстракцией заявки; это означает, среди прочего, что если вы когда-нибудь захотите изменить способ реализации структуры ответа, вам нужно будет изменить код только в одном месте (в рамках реализации Ticket). Все остальное просто обращается к API.
$ticket->getReplies()->get(id)->update(...)
Это классический анти-узор; потребитель должен знать о Ticket больше, а не меньше, и поэтому изменить реализацию Ticket сложнее, чем проще.
Кроме того, поскольку вы позволяете потребителю напрямую обновлять ответы, вы не позволяете Ticket защищать структуру ответов; теперь любые проверки на соответствие / согласованность должны выполняться каждым потребителем, а не единовременно.
В качестве соображения дизайна: тот факт, что вы хотите получить ответы через Ticket, может быть попыткой сказать вам, что Reply должен быть отдельным агрегатом от Ticket. Тот факт, что сущность Reply и сущность Ticket имеют отношение, которое их объединяет, не означает, что они должны быть частью одного и того же агрегата.
Спасибо за объяснение