Вопросы по существу по DDD

[MaratCrash]

1. Верно ли я понимаю, что:
application - сервисы
domain - доменый слой (сущности, интерфейсы репозиториев, фабрики, стратегии и т.д. - то что помогает работе сущности)
infrastructure - реализация интерфейсов репозиториев
presentation - контролеры, вьюхи

2. Где нужно размещать код по созданию сущности? Почему не стоит метод create (EntityDTO $dto) в самой сущности? ПРОсто часто замечаю, что код по созданию сущности выносят в сервис, в сервисе же вызывают репозиторий.

3. Вызывать репозиторий в сущности верный подход? Это ведь по сути один слой. Значит они могут знать друг о друге. Это я снова к вопросу №2 про создание сущности.

4. Насколько верно то, что сущность будет знать про DTO? не совсе мверно, как по мне. Если так, то поулчается наши DTO-шки тоже явля.ются частью домена.


Спасибо.

[zelenin]

1. Верно ли я понимаю, что:
application - сервисы

сервисы - слишком общее название. Сервисами является практически все, что не обладает состоянием. Опять же в ddd есть сервисы application, domain и infrastructure слоев.
Но в целом упрощенно application можно понимать как сервисный слой (прокладка между контроллерами и доменом).

domain - доменый слой (сущности, интерфейсы репозиториев, фабрики, стратегии и т.д. - то что помогает работе сущности)
infrastructure - реализация интерфейсов репозиториев
presentation - контролеры, вьюхи

в общем да

2. Где нужно размещать код по созданию сущности? Почему не стоит метод create (EntityDTO $dto) в самой сущности? ПРОсто часто замечаю, что код по созданию сущности выносят в сервис, в сервисе же вызывают репозиторий.

ddd неразрывно с SOLID, а первое S означает "единственная/единичная ответственность".
Плюс нет какого-то единичного маппинга между DTO и сущностью. Одна сущность может создаваться в различных эндпойнтах (экшнах) с различным количеством входных данных и соответственно с разными DTO, обрабатываемыми разными хэндлерами.

3. Вызывать репозиторий в сущности верный подход?

приемлемый

Это я снова к вопросу №2 про создание сущности.

поясни

4. Насколько верно то, что сущность будет знать про DTO?

не верно. DTO просто выполняет служебные функции в контексте приложения (app layer) для переноса данных между реквестом и и сервисом в общем случае

[MaratCrash]

1. Верно ли я понимаю, что:
application - сервисы

сервисы - слишком общее название. Сервисами является практически все, что не обладает состоянием. Опять же в ddd есть сервисы application, domain и infrastructure слоев.
Но в целом упрощенно application можно понимать как сервисный слой (прокладка между контроллерами и доменом).

А в чем суть доменных сервисов, когда я могу создать служебные классы в домене - стратегии и фабрики те же самые, к примеру?

3. Вызывать репозиторий в сущности верный подход?

приемлемый

Это я снова к вопросу №2 про создание сущности.

поясни

Это я про то, насколько корректно в методах сущности использовать интерфейсы репозиториев. Смысл этого вижу в том, чтобы не дублировать участки кода в сервисном слое. К примеру, необходимо сравнить сущность с другой (того же типа сущности). Для этого необходимо считать сущность (с которой сравниваем) из хранилища.

4. Насколько верно то, что сущность будет знать про DTO?

не верно. DTO просто выполняет служебные функции в контексте приложения (app layer) для переноса данных между реквестом и и сервисом в общем случае

Понятно. А где DTO должна "теряться"? К примеру, прилетает в контроллер, мы далее передаем DTO-ку в вызываемый сервис. Вот там получается из DTO извлекается все необходимое, оформляется в сущность и передается дальше, так?

[zelenin]

А в чем суть доменных сервисов, когда я могу создать служебные классы в домене - стратегии и фабрики те же самые, к примеру?

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

3. Вызывать репозиторий в сущности верный подход?

приемлемый

Это я снова к вопросу №2 про создание сущности.

поясни

Это я про то, насколько корректно в методах сущности использовать интерфейсы репозиториев. Смысл этого вижу в том, чтобы не дублировать участки кода в сервисном слое. К примеру, необходимо сравнить сущность с другой (того же типа сущности). Для этого необходимо считать сущность (с которой сравниваем) из хранилища.

я про создание сущности прошу пояснить. Не вижу тут места созданию сущности. Тем более репозиторий уже готовую вернет.

4. Насколько верно то, что сущность будет знать про DTO?

не верно. DTO просто выполняет служебные функции в контексте приложения (app layer) для переноса данных между реквестом и и сервисом в общем случае

Понятно. А где DTO должна "теряться"? К примеру, прилетает в контроллер, мы далее передаем DTO-ку в вызываемый сервис. Вот там получается из DTO извлекается все необходимое, оформляется в сущность и передается дальше, так?

так.

[slavcodev]

не верно. DTO просто выполняет служебные функции в контексте приложения (app layer) для переноса данных между реквестом и и сервисом в общем случае

Понятно. А где DTO должна "теряться"? К примеру, прилетает в контроллер, мы далее передаем DTO-ку в вызываемый сервис. Вот там получается из DTO извлекается все необходимое, оформляется в сущность и передается дальше, так?

так.

А я вот думаю не так.

DTO (Data Transfer Object) объект передачи данных из одного слоя в другой, без разницы какие.

[zelenin]

Понятно. А где DTO должна "теряться"? К примеру, прилетает в контроллер, мы далее передаем DTO-ку в вызываемый сервис. Вот там получается из DTO извлекается все необходимое, оформляется в сущность и передается дальше, так?

так.

А я вот думаю не так.

DTO (Data Transfer Object) объект передачи данных из одного слоя в другой, без разницы какие.

ну мы про конкретный кейс, т.к. в общем dto - просто объект передачи данных, без слоев.

[MaratCrash]

так.

А я вот думаю не так.

DTO (Data Transfer Object) объект передачи данных из одного слоя в другой, без разницы какие.

ну мы про конкретный кейс, т.к. в общем dto - просто объект передачи данных, без слоев.

Так Вы DTO и в сущности передаете?

[zelenin]

А я вот думаю не так.

DTO (Data Transfer Object) объект передачи данных из одного слоя в другой, без разницы какие.

ну мы про конкретный кейс, т.к. в общем dto - просто объект передачи данных, без слоев.

Так Вы DTO и в сущности передаете?

с чего вы так решили?

[MaratCrash]

ну мы про конкретный кейс, т.к. в общем dto - просто объект передачи данных, без слоев.

Так Вы DTO и в сущности передаете?

с чего вы так решили?

Сори, промахнулся, вопрос больше наверное к slavcodev. Т.к. он написал, что для DTO неважно в какой слой прилетать. Как по мне, если DTO в сущности передавать, то тогда эти DTO придется перетащить в доменный слой. Что не совсем гуд.

[zelenin]

Так Вы DTO и в сущности передаете?

с чего вы так решили?

Сори, промахнулся, вопрос больше наверное к slavcodev. Т.к. он написал, что для DTO неважно в какой слой прилетать. Как по мне, если DTO в сущности передавать, то тогда эти DTO придется перетащить в доменный слой. Что не совсем гуд.

ну он прав - dto это понятие не какого-то определенного слоя, но про передачу dto в сущности он ничего не писал.

Вы поймите, что dto - это просто "объект для переноса данных". Он не несет какого-то специфического для ddd значения. Просто в ddd оно обычно служит для переноса данных из реквеста в сервис.

[MaratCrash]

Так почему он прав, если в сущности нельзя DTO кидать?! То что DTO можно кидать в другие слои и таскать с контролеры в сервисы, а из сервисов в другие сервисы - это все понятно

[zelenin]

Так почему он прав, если в сущности нельзя DTO кидать?!

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

[MaratCrash]

Понял.
Как Вы думаете:
1. Я сейчас делаю валидацию (первичную) на уровне контроллера. Нужно ли делать валидацию на уровне сущностей? Мне кажется, это оверхед.
2. Создание сущностей Вы где делаете? Про экшнКОнтроллера-МетодСервиса понятно. Сервисы вообще получаетстя нужны ислючительно как связующее звено (я про уровень Application). Так во тв самом сервисе Вы вызываете репозиторий или же вызываете нечто другое? Условие - сущность без зависимостей от других сущностей, все просто.

[zelenin]

Понял.
Как Вы думаете:
1. Я сейчас делаю валидацию (первичную) на уровне контроллера. Нужно ли делать валидацию на уровне сущностей? Мне кажется, это оверхед.

Валидировать можно dto, из которого будет создана сущность. Можно базовую валидацию делать тайп хинтингом в сигнатуре конструктора, можно в самом конструторе или методах сущности также валидировать входящие данные. Но в целом слой валидации должен быть в сервисах.

2. Создание сущностей Вы где делаете? Про экшнКОнтроллера-МетодСервиса понятно. Сервисы вообще получаетстя нужны ислючительно как связующее звено (я про уровень Application). Так во тв самом сервисе Вы вызываете репозиторий или же вызываете нечто другое? Условие - сущность без зависимостей от других сущностей, все просто.

ну передаете dto в сервис, валидируете, создаете напрямую или фабрикой сущность, сохраняете в репозитории.

[MaratCrash]

Бывают такие ситуации, когда придется в репозиторий передавать 10 параметров в метод Вы в тиаком случае тоже DTO не использщуете? И если нет, то как решаете такой момент? Прописывать в мето все 10 параметров - сигнатура становится адски несносной, мягко говоря

[zelenin]

Бывают такие ситуации, когда придется в репозиторий передавать 10 параметров в метод

например?

Вы в тиаком случае тоже DTO не использщуете?

dto в общем смысле или в конкретном, про который до этого общались?

И если нет, то как решаете такой момент? Прописывать в мето все 10 параметров - сигнатура становится адски несносной, мягко говоря

дело вкуса. Конкретно к архитектуре не относится. Вообще почитайте ветки соседние - мы тут уже все основные вопросы обсуждали, в т.ч. queryobject для репозитория.

[slavcodev]

Сори, промахнулся, вопрос больше наверное к slavcodev. Т.к. он написал, что для DTO неважно в какой слой прилетать. Как по мне, если DTO в сущности передавать, то тогда эти DTO придется перетащить в доменный слой. Что не совсем гуд.

DTO - я считаю просто массив данных представленный объектом. Для чего? Для type-hinting аргументов или return type. Со свойствами класса удобнее работать чем с ключами массива, особенно при рефакторинге и тестах.

Исходя из этого, да DTO можно передавать в сущность.

Предполагаю под "перетащить в доменный слой", ты имеешь виду неймспейс класса, и хотя я не большой фан группировки классов по слоям, но не вижу ничего плохого существование DTO класса в доменной слое, если он к нему относится.

[MaratCrash]

Понятно.
А где вы размещаете адаптеры различные? К примеру, у меня конкретный случай. Есть билинг провайдер. И отправку запросов по АПИ я делаю гузлом (guzzle). Причем биллинг провайдер может меняться и это нужно учесть в коде. Вот момент работы с гузлом размещат ьв домене, как я полагаю, не верно. Делаю адаптер для этого, интерфейс адаптеры в домене, но вот куда положить реализацию задумался Вроде как это слой приложения (Application) больше.

[zelenin]

провайдеры могут быть разными, их может быть много, реализации могут быть большими - прекрасный момент для выноса в отдельный модуль. А в нашем конкретном домене оставить только интерфейс сервиса оплаты.

[MaratCrash]

Интерфейс я как раз и оставляю в домене, да. А вот реализацию выношу, это да. Но куда именно это вы бы вынесли? Я сейчас это вынес все на уровень Application. НЕ в сервисы, а просто в отдельные класссы, которые подтягиваю в сервисах нужных.