зачем? если тянуть из базы не через * то да в 2х местах

ну мы ж не хотим что бы у нас приложение педалило

ок, тогда вопрос, зачем в БД придумали view?

ок, тогда вопрос, зачем в БД придумали view?

а как тебе тут view поможет?)

view для того и нужен чтобы ограничивать видимость полей в том числе по определенным условиям

да, но с пользователями в CRM это нам не поможет, так?

я согласен что вьюшки это хорошо, но в случае с one-to-many всеравно будут проблемы с гидрацией которую надо где-то делать

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

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

у нас апишка, забыл?

наш респондер это сферический сериалайзер

не важно, если он чуть сложнее чем json encode то придется

ок в случае одного заказа

но с теми же полями - тот же домен, метод getById

но с теми же полями - тот же домен, метод getById

а статус менять кто будет?

не важно, если он чуть сложнее чем json encode то придется

придется что?

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

я конечно слабо представляю зачем в одном запросе и менять статус и получать заказ, но раз так надо, то через домен заказов обновляем статус, через домен OrdersWithFullDetailsDomain получаем заказ

естественно все это внутри домена страницы

я конечно слабо представляю зачем в одном запросе и менять статус и получать заказ, но раз так надо, то через домен заказов обновляем статус, через домен OrdersWithFullDetailsDomain получаем заказ

что бы второй раз за актуальным состоянием на сервер не ходить. Единственный вариант получше - отправлять сокетами отдельно. Тут к слову тоже вопрос - как бы ты это делал в условиях ADR

ну мол отправка через сокеты -> послать запрос на хрень которая с сокетами работает и в запрос запихнуть ту самую json-ку которую мы хотим что бы все пользователи получили

во первых я бы разбил на 2 запроса

во первых я бы разбил на 2 запроса

по условиям задачи - нельзя

во вторых я не вижу смысл тянуть весь заказ

во вторых я не вижу смысл тянуть весь заказ

что-то могло поменяться)

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

но меня сейчас вопрос с сокетами интересует

в этом случае у тебя в экшен данные не надо возвращать, но эти данные надо прокинуть (через респондер) на внешний сервис по http

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

так стоп

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

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

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

так как там будет json encode по сути, то достаточно выплюнуть данные в домен работы с этим API

так как там будет json encode по сути, то достаточно выплюнуть данные в домен работы с этим API

не, там скорее всего будет какой-то symfony/serializer что бы хэндлить всякие даты и прочие деньги

в любом случае это уже забота того домена который работает с API

это его зона ответственности

короч ладно, мне наскучило. Потому последний вопросик: можно ли заменить термин "домен" на "приложение"? А "эктор" на адаптер (ведь все что он делает это конвертирует http запрос в вызов приложению). Тогда респондер будет просто изолированная штука которую использует адаптер что бы сконвертировать данные в нужное представление

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

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

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

вопрос зоны ответственности. Я например на запись и на чтение стараюсь разные штуки использовать. Но в целом ничего.

респондер это то, что формирует ответ

респондер это то, что формирует ответ

но ответ формирует домен) респондер по твоей версии лишь преобразовывает представление данных

насчет экшна я бы скорее сказал что это что то вроде команды, но не адаптер

домен - формирует пакет данных для респондера

нет "домен" нельзя заменить "приложением"

домен - формирует пакет данных для респондера

в чем разница между формированием пакета данных и формированием респонса?

нет "домен" нельзя заменить "приложением"

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

можно написать программу которая выполнится и на php и на c используя один файл исходников (языки могут быть иные, чисто для примера), но в одном случае это php в другом c, все зависит от контекста

насчет экшна я бы скорее сказал что это что то вроде команды, но не адаптер

дай определение паттерну "команда" и паттерну "адаптер". А потом скажи чем именно занимается экшен

как минимум у ответа есть код

можно написать программу которая выполнится и на php и на c используя один файл исходников (языки могут быть иные, чисто для примера), но в одном случае это php в другом c, все зависит от контекста

не очень понял суть

как минимум у ответа есть код

у какого ответа? http который?

да

да, но это всеравно не формирование а трансформация

исключения - в 4xx или 5xx с каким-то телом, а если все хорошо - 2xx - то что задал контекст.

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

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

поменяется еще как

не я же адаптер командами называю

так не надо все яйца в одну корзину

так не надо все яйца в одну корзину

https://github.com/pmjones/adr/blob/master/IMPLEMENTATION.md#action

ADR это про Web, если нужно CLI приложение на php можно заниматься только доменами из ADR, сам ADR не про это

ADR это про Web, если нужно CLI приложение на php можно заниматься только доменами из ADR, сам ADR не про это

я к тому что Action в контексте ADR это адаптер http -> приложение

ты можешь внутри экшена из http запроса сформировать команду и юзать тот самый command pattern

далее, респондер. Тот же твиг или symfony/serializer - это примеры штук которые полностью инкапсулируют в себе UI логику.

Action это action, это не адаптер

Action это action, это не адаптер

Action - название сущности в триаде Action-Domain-Responder. Выполняет роль адаптера между http и Domain. Так?

или он какую-то другую роль выполняет?

The key heuristic of the Action is it should contain almost no logic at all. It collects input from the HTTP request, passes that input to the Domain, then hands control over to the Responder. The Action is intentionally very spare. Handle any business logic in the Domain and any presentation logic in the Responder. The only exception here is the Action may provide default values for user inputs when they are not present in the HTTP request; this is easily handled via ternaries rather than if/then blocks.

ERROR: S client not available

twig это не responder

не надо путать шаблонизаторы с responder

шёл второй день...

главное не скучно

Action это action, это не адаптер

в суть гляните слов, да поймете может

не надо путать шаблонизаторы с responder

$responder = function ($data) use ($twig) { return new Response($twig->render('template.twig', $data)); };

чем не респондер)

тем, что не может быть use

тем, что не может быть use

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

тем не менее action ничего про твиг знать не может

кроме того это уж очень упрощенный responder

где обработка случаев когда в payload статус ошибки например?

где обработка случаев когда в payload статус ошибки например?

вот хороший вопрос - как ты будешь хэндлить исключения?

какие исключения?

или это задача домена сконвертить исключения в некий пэйлоад

именно

именно

у Пауля этим экшен занимается)

вообще - нет

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

ладно, пусть живет

я допускаю что ADR в условиях любителей пописать логику в контроллерах скорее хорошо нежели бесполезно

просто это капля в море

не могу не согласиться, ADR - это не панацея

есть скажем еще CQRS - оно позволяет тебе сделать чуть по другому, когда у тебя операция записи и чтения происходят через разные интерфейсы (разные зависимости). И этот подход очень плохо вяжется с ADR в ситуации когда хочется что-то вернуть после записи. Хотя в целом, возможно желание что-то вернуть после записи само по себе опасно. Вернул айдишку и норм. А для синхронизации - сегодня поднять сокеты можно на раз два.

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

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

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

а теперь к сервисам - все что ты там доменами назвал по сути является сервисами.

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

потому я не люблю ADR

вот я тоже в эту сторону думаю последнее время

для меня домен - это доменная модель. Которая представлена сервисами, сущностями и VO и вообще сложная штука.

а для "что-то что что-то делает" и так был термин сервис