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

![5e50ddcd8d259532342263.png](https://habrastorage.org/webt/5e/50/dd/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...](https://m.dotdev.co/design-pattern-service-layer-with-laravel-5-740ff0a7b65f)  

тут же вообще сервис это место для выноса кода из контроллера, это норм? Или сервис в ларавел подразумевает не то что сервис в DDD?  

  

Прошу помочь и внести ясность. 

 Вот отличная книга на русском.  

Даст некое понимаение может, но как по мне книга не для новичков.  

<https://github.com/adelf/acwa_book_ru> 

 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> 

 Не как основной ответ, а скорее, как дополнение к предыдущим.  

Несколько месяцев назад кинули мне в виде тестового задания написать форму на vue.js и Laravel. Обязательно используя DDD. Получился очень базовый пример и сама структура построена на основе кучи прочитанных постов про подход DDD (в основном англоязычных).  

<https://github.com/Kulaxyz/DDD-Laravel-Form?files=1>  

В итоге кстати задание приняли и оценили высшим балом)