кстати у меня как раз очень тонкие действия выходят, по размеру примерно как в том видео где сервисы размер сервиса

не понял

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

у действия и так одна зона ответственности, вопрос в том у тебя действие это invokable класс или просто метод класса

тогда из еще можно сгруппировать по пересечению зон ответственности вместе

на маленьких проектах как бы плевать, а если у тебя хотя бы пара сотен экшенов уже не так удобно

invokable класс естественно

короч я так подумал - лучше зайти к этому вопросу с другой стороны. Как у тебя выглядит Domain в терминах ADR?

если совсем в общем - его зона ответственности - подготовка данных, которые будут выведены

если более частно - кошмарно, думаю надо еще почитать посмотреть про сервисы, вполне возможно чего то подобного мне не хватает в доменах

если совсем в общем - его зона ответственности - подготовка данных, которые будут выведены

а откуда данные выводятся и как они попадают туда где лежат?

если более частно - кошмарно, думаю надо еще почитать посмотреть про сервисы, вполне возможно чего то подобного мне не хватает в доменах

я думаю ты не очень так и разобрался с ADR

но пока не уверен

возможно опять проблема с терминологией

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

типа name, email, password

хм...

должно выглядеть примерно как domain->addUser(request);

так стоп не совсем

return responder->__invoke(domain->addUser(request));

return responder->__invoke(domain->addUser(request));

то есть http request просачивается в domain?

в данный момент да

ну значит ты не разобрался с ADR

да я понимаю, что не должен

но сейчас выглядит так

да я понимаю, что не должен

ну то есть вообще никакого разделения ответственности ты тут не имеешь. Это то же самое что json_encode($domain->addUser($request);

но сейчас выглядит так

а как должно?)

если совсем в общем - его зона ответственности - подготовка данных, которые будут выведены

ну и как мы выяснили - задача "домена" не только в подготовке данных для UI но и в записи. То есть уже 2 ответственности на одном компоненте. А потому вопрос - а нахер тогда респондер и в чем его зона ответственности?

по логике должно быть примерно так return responder->invoke(domain->addUser(name, email, password));

вот насчет 2х ответственностей я подохреваю что тут проблема

а responder обрабатывает пришедшие данные и подготоваливает response

заголовки, тело страницы и т.д.

могу ли я скормить айдишку респондеру что бы тот сгенерил респонс и он сам знал что откуда доставать?

это ж по сути тоже преобразование

нет

то есть. если мне нужен json - мне выходит что не нужны респондеры?

я ж могу тупо сделать return $this->json($domain->addUser(...$request));

респондеры имеют следующий заголовок __invoke(payload)

респондеры имеют следующий заголовок __invoke(payload)

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

это зона ответственности домена

это зона ответственности домена

в каждом запросе нам помимо кусочка данных надо будет тянуть данные для всей страницы?

в каждом, Карл

то есть связанность системы взлетает до небес

зачем?

ну потому что надо что бы домен предоставил всю инфу которая будет на страничке, с твоих слов

именно

но ты же не всегда всю страницу тянешь?

в каждом, Карл

^

но ты же не всегда всю страницу тянешь?

предположим что у меня нет фэнси ajax-ов и т.д. и мы говорим о классическом WEB (ибо там где фэнси SPA мне не нужен респондер ибо у меня это будет просто json_encode по твоей логкие)

для веба да, но для классического веба по другому никак

если конечно не пользвоаться iframe

кроме того иногда не json encode а все же отрендереный кусок страницы

ох сколько нам открытий чудных....

ну не отправлять же сразу все шаблоны клиенту?

> по другому никак Что ты знаешь о HMVC? компонентные подходы? UI как композиция элементов? каждый со своим провайдером данных и т.д.?

ну не отправлять же сразу все шаблоны клиенту?

так SPA работают)))

иерархическая система MVC, триады каждая со своей зоной ответственности

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

вообще никакого

даже pmjones не такую вредную хрень предлагает

с чего бы?

ну потому что то что ты описал отличается от того что он пишет в описании ADR

и закончим тем какой объем связанности порадит такая херня

никакой

никакой

удачи

мой тебе совет - забудь о MVC, ADR и т.д.

и лучше разберись с тем что такое связанность и с идеей "Dependency as code smell"

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

я знаю что такое связанность

ERROR: S client not available

ну что-то не похоже

пилю тестовое задание и думаю "А нафига мне маппить данные полученные из запросов в объекты, если мне их только юзеру передать?". Типа может просто массив зафигачить и бог с ним? Всё равно никакого поведения у объектов не будет.

ну DTO - это массивчик на стероидах

мне сейчас для них только readonly пропертей не хватает... можно было бы поиграться с __get, но не хочется терять автокомплит

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

если бы в php приложении структура данных выплевывалась клиенту строго в одном месте - то и обычный массивчик неплохо подойдет для решения проблемы

поскольку у нас конструирование и описание структуры будет строго в одном месте

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

чтобы не делать !empty()

на 10 мест

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

ну а если все что ты делаешь - это делаешь echo json_encode($dto);?)

и тебе не надо знать структуру этого DTO кроме как в месте, где ты его конструируешь

по сути ДТО это валидация при создании , в массиве при получении

по сути ДТО это валидация при создании , в массиве при получении

ты смешиваешь концепции

это не помогает

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

ты смешиваешь концепции

я про момент передачиданных на вход сервиса

ну DTO - это массивчик на стероидах

просто получается, что репозиторий (а логично ли его называть репозиторием, если он возвращает только view-model?) возвращает то же самое, что application service, который его вызывает =\

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

опять же такого рода заявления так же никак не помогают людям понять когда юзать одно и когда другое и вообще зачем они это все юзают

в самом сервисе или делаем валидацию или перекладываем ее на дто конструктор

я про момент передачиданных на вход сервиса

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

а если на выход - есть возможность сделать так что структура нам снаружи и не особо интересна (хотя на самом деле интересна, но это можно статическими анализаторами вытащить)

да, но если условно на вход был массив , где обязательные 3 элекмента, то как вариант можно передать их отдельными параметрами, а не внутри массива

просто получается, что репозиторий (а логично ли его называть репозиторием, если он возвращает только view-model?) возвращает то же самое, что application service, который его вызывает =\

я просто вообще не понял твою задачу ты получаешь данные и срзу их отдаешь?

я просто вообще не понял твою задачу ты получаешь данные и срзу их отдаешь?

ну элементарно запрос в РБД, который мне надо показать юзверю

я просто вообще не понял твою задачу ты получаешь данные и срзу их отдаешь?

агрегация например какая-то, группировка

ну здесь вопрос в том, уверен ли ты в том, что получишь то, что тебе нужно

да, но если условно на вход был массив , где обязательные 3 элекмента, то как вариант можно передать их отдельными параметрами, а не внутри массива

type MyDTO = { foo: int bar: string baz: float } function fooBar(dto: MyDTO) {} fooBar({ foo: 12, bar: "bar", baz: 3.14 })

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

ну здесь вопрос в том, уверен ли ты в том, что получишь то, что тебе нужно

в смысле будут ли 100% в результатах запроса какие-то поля?

да

и хочешь ли ты отдать проверку этого клиенту