@equentor

Как называть классы сервисов домена в DDD? И на сколько применим сервисный слов в Laravel?

5e50ddcd8d259532342263.png
Насколько я понимаю в DDD сервисный слой содержит в себе логику юзкейсов, манипулируя сущностями/аггрегатами (через вызов их методов, содержащих БЛ). Тогда такой вопрос, а как вообще называть сервисные классы? На чём они завязаны? Например, есть банальное действие регистрации пользователей, тогда сервис будет называться UserRegistrarService (сущ. будто говоря что класс отвечает за конкретное действие - за регистрацию пользователей (единая ответственность)) и содержать в себе метод register(User $user); или же это должен быть глагол описывающий действие UserRegistrationService::register(User $user), а-ля юзкейс; Или это просто UserService::register(User $user) - как бы завязываем сервис на конкретной сущности или агрегата?

И второй вопрос, применим ли сервисный слой в Laravel с его Eloquent? В связке Repository + DataMapper понятно, сервис обращается к репозиторию, получает сущность или агрегат, вызывает методы этого агрегата, а может и не одного, в зависимости от кейса, и при таком подходе хочется делать доменные объекты наполненными БЛ. Но в случае с ёлкой.. Она и так содержит инфраструктурную логику, пихать туда ещё и бизнес? И получается что сервис в ларавель завязывается на обслуживании анимичной модели (содержащей только геттеры-сеттеры, методы описывающие связи и скоупы), грубо говоря выносим в него БЛ. Получается что суть DDD о БЛ в доменном объекте - теряется.

https://m.dotdev.co/design-pattern-service-layer-w...
тут же вообще сервис это место для выноса кода из контроллера, это норм? Или сервис в ларавел подразумевает не то что сервис в DDD?

Прошу помочь и внести ясность.
  • Вопрос задан
  • 136 просмотров
Пригласить эксперта
Ответы на вопрос 3
@vism
Вот отличная книга на русском.
Даст некое понимаение может, но как по мне книга не для новичков.
https://github.com/adelf/acwa_book_ru
Ответ написан
@EvgeniiR
https://github.com/EvgeniiR
DDD - оно в целом не про проектирование приложений, а про общение с бизнесом и моделирование сложных предметных областей понятных как доменному эксперту так и разработчикам.
Хотите учиться архитектуру делать - лучше читать про архитектуру.

Например, есть банальное действие регистрации пользователей, тогда сервис будет называться UserRegistrarService (сущ. будто говоря что класс отвечает за конкретное действие - за регистрацию пользователей (единая ответственность)) и содержать в себе метод register(User $user); или же это должен быть глагол описывающий действие UserRegistrationService::register(User $user), а-ля юзкейс; Или это просто UserService::register(User $user) - как бы завязываем сервис на конкретной сущности или агрегата?

Вообще, User - часто неудачное название агрегата, потому что логин-пароль, описание профиля, маркетинговые идентификаторы, адрес доставки товаров и пр., если такое у вас есть, не используются в одном месте.
Завтра, возможно, вы захотите аутентификацию вообще на отдельный auth-сервер вынести.

Сервис ради сервиса не нужен - хотя бы потому что контроллер тоже может быть доменным сервисом: аргумент резолверы валидируют и десереализуют запрос, и вжух - контроллеры уже отвязаны от HTTP и работают с DTO конкретных команд.

И второй вопрос, применим ли сервисный слой в Laravel с его Eloquent?

В Eloquent модельках - не особо. Хотя можно попробовать -одна бизнес транзакция = 1 агрегат(так и должно быть в идеале), провели транзакцию и сохранили модель. На чтение модельки не использовать.
Хотя зачем для этого Eloquent использовать не ясно тогда.

И получается что сервис в ларавель завязывается на обслуживании анимичной модели (содержащей только геттеры-сеттеры, методы описывающие связи и скоупы), грубо говоря выносим в него БЛ.

В Laravel используется Active Record. AR по определению - штука которая отвечает за бизнес-логику и за работу с хранилищем, и да - нарушает SRP.
Нужно оно, по идее - чтобы простые приложения клепать и не заморачиваться с мапперами и всякими CQRS, хотя я считаю что не нужно в принципе.

Получается что суть DDD о БЛ в доменном объекте - теряется.

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

Кстати, про развитие практик разработки в PHP - очень советую глянуть доклад - https://www.youtube.com/watch?v=v1I57-_Rsv0
Ответ написан
Kulaxyz
@Kulaxyz
Могу лучше
Не как основной ответ, а скорее, как дополнение к предыдущим.
Несколько месяцев назад кинули мне в виде тестового задания написать форму на vue.js и Laravel. Обязательно используя DDD. Получился очень базовый пример и сама структура построена на основе кучи прочитанных постов про подход DDD (в основном англоязычных).
https://github.com/Kulaxyz/DDD-Laravel-Form?files=1
В итоге кстати задание приняли и оценили высшим балом)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы