Comments 8
Очень часть под use case как раз и понимают application service
Согласен, на этот счет вообще часто возникают недопонимания между людьми. У меня такой подход к именованию прежде всего связан с опытом работы на одном проекте, где мы называли компоненты таким образом.
Фактически, получается, что операции выполняются UseCase'ами, а ApplicationService является скорее неким фасадом, который объединяет их, а также выполняет управление транзакцией в процессе выполнения UseCase'a
Но всё же, для меня это было не столько разработка действительно уникального сервиса, сколько испытание моих способностей. К тому же, недавно я начал глубоко погружаться в подходы проектирования и мне нужно было на чем-то опробовать то, что я прочитал.
Для решения поставленной задачи проект явно переусложнен и совершенно необозрим.
Но раз вы его позиционируете как учебный, для обучения всем этим наилучшим практикам разработки из трудов теоретиков - нормально: эту задачу он решает. Главное, чтобы потом, в практической работе, все эти "наилучшие практики" не мешали. Но это обычно с опытом приходит.
Спасибо за комментарий!
Да, действительно для реализации тех функций, которые изначально планировались и были в итоге реализованы в системе на данный момент, проект сильно переусложнен, полностью согласен. И да, всё же преимущественно я использовал такие подходы с целью лучшего понимания и применения теоретических навыков на практике.
Но я также рассматриваю спланированную архитектуру больше не с точки зрения разового преимущества, а скорее заложения определенного фундамента под будущие изменения. Кто знает, может быть, проект действительно заинтересует кого-то и потребуется его дальнейшая доработка с добавлением возможностей, отличных от простых публикаций/чтения статей :)
В то же время, некоторые компании порой не придают большого значения планированию развития проекта, из-за чего возникают ситуации, когда переписывать требуется целые системы, что довольно затратно.
Да, главное - находить некую "золотую середину" между сложными в реализации и понимании подходами и сведению всей системы к "контроллер-репозиторий".
А в чем преимущество ArticleApplicationService , если он только проксирует запросы UserCases, почему не обращаться сразу к UserCase?
Методы сервиса получаются просто "обертками" над методом UseCase'ов. Это получается достаточно удобно в моментах, когда требуются дополнительные операции, связанные с выполнением каждой операции.
Например, таким образом удобно управлять транзакцией вместо того, чтобы открывать и закрывать её отдельно в каждом UseCase. Также, таким образом, после выполнения операции можно вызвать обработку всех событий предметной области, произошедших в процессе выполнения операции. А еще можно добавить туда мониторинг и логирование (если по каким-то причинам вы не используете Middleware, конечно), либо просто замерять скорость выполнения UseCase.
Разработка сервиса для публикации препринтов. Архитектурный подход