Михаил
... если понадобится шарить функционал
... если не сделаешь то будет копиться
очень много если. Просто создаёшь папку с модулем и через интерфейсы ограничиваешь входящие зависимости, всё. Если понадобится модуль сделать в виде бандла - то просто выносишь его в бандл. У меня в проекте сотни микромодулей, я не хочу каждый раз открывать новую вкладку в ide для редактирования модуля.
Юра
Мы наверное о разном говорим
Nikolay
Если бандл заранее сделан в виде модуля, это облегчает навигацию по проекту, делает более явными разграничения и легко позволяет вынести бандл в пакет если вдруг понадобилось на нескольких проектах использовать функционал
У бандла много лишних конфигов, которые модулю не нужны
Dmitriy
Бандлы с бизнес логикой прошлый век
Give
Всем привет, вопрос по DDD, нормально ли делать интерфейс DTO в Application слое, а реализовывать в Infrastructure?
Просто в кодовой базе гуляет 2 варианта, где просто в Application лежат реализации DTO и где через интерфейс с реализацией в Infrastructure
Dmitriy
Нет, у дто нет поведения
The Ant
Give
На дто вообще интерфейс не нужен
это я понимаю, просто проект видимо был из легаси, в этих дто на уровне инфраструктуры построена валидация на пхп доках и видимо что бы слой не протекал решили так поступить
Михаил
это я понимаю, просто проект видимо был из легаси, в этих дто на уровне инфраструктуры построена валидация на пхп доках и видимо что бы слой не протекал решили так поступить
Пхпдоки, атрибуты это ничто, пустое место. Ты хоть в доменном слое их можешь лепить.
Валидацию следовало бы разделить. В слое инфраструктурном, при запросе сделать валидацию на типы, на значения enum, на положительность числа, на структуру итд.
А всякие бизнес проверки заключить в доменном слое, тогда протечек не будет.
Dmitriy
Просто модули
Юра
Что такое модули?
Nikolay
Что такое модули?
На примере пхп это сложно объяснить, в других языках есть конструкции. Есть modulite как попытка сделать модули
Юра
На примере пхп это сложно объяснить, в других языках есть конструкции. Есть modulite как попытка сделать модули
На Хабре первый комментарий про этот модулит толкового объясняет почему это бесполезная штука
Юра
karrakoliko
22 дек 2022 в 11:24
Кажется что проблема должна решаться с другой стороны: когда мы хотим понять состояние дел, некая консольная тулза вроде phpstan может пробежаться по проекту/классу/всем классам неймспейса, собрать все import/new, и отобразить в консоли как warning все обращения к внешним классам, которых там быть не должно.
Не огораживание-драйвен-дев (ради потенциальной возможности когда-нибудь удобнее разбить монолит), а чтобы при необходимости разбить монолит можно было удобнее провести рефакторинг, для которого описанная выше тулза и пригодилась бы.
Юра
Еслт проблему можно решить простым способом, не нужно ее решать сложным способом
Nikolay
Nikolay
Только там тоже есть проблемы, когда надо выделить приватную и публичную часть модуля приходится изворачиваться
Юра
Ну понятно. В айти невозможно решить одну проблему не создав новую. Закон сохранения проблем
Юра
Единственное что можно это попробовать сложную проблему превратить в ряд менее сложных проблем
Nikolay
Единственное что можно это попробовать сложную проблему превратить в ряд менее сложных проблем
Либо перейти на другой язык
Юра
Там другие будут проблемы
Михаил
Что такое модули?
Модуль создания отчётов, модуль оплаты, модуль чата
Что-то изолированное и полное. То есть некий набор классов объединённые одной идеей. То что технически ты можешь вынести в пакет.
Михаил
Ну и да, технически модуль можно вынести в микросервис, но не всегда
Юра
У нас на работе например есть отдел архитекторов, при создании нового пакета нужно получить апрув, если пакет нигде не используется больше кроме одного проекта то репу не дадут создать под него
Юра
Не говоря уже о микросервисе
Vlad
Можно посмотреть выступление Валентина на эту тему )
Или Елисеева, у него есть доклад где он ссылается на выступление Валентина Удальцова.
Login
Можно посмотреть выступление Валентина на эту тему )
Можно ссылку пожалуйста, или полное имя автора?
Vlad
https://www.youtube.com/watch?v=EvVSxVzFEUg&t=2338s
Юра
У меня вопрос. Где принято делать flush?
Shokha
У меня вопрос. Где принято делать flush?
У меня свой Flusher везде его использую, в репо у меня нету flush
Kirill
с одной стороны в репозиториях
The Ant
С другой в контроллерах? )
Юра
У нас на работе к примеру в контроллере делают, в сервисах не делают
Vite4eg
Юра
И вроде получается сервису не нужен вообще энтити менеджер, но нужно делать persist и только ради этого его туда тянуть
Kirill
а на чтение или запись уже не важно
Юра
Зачем флаш при чтении )
The Ant
ну в контроллерах - это изврат полный)))
Ты не можешь знать кто и где зафлашит. Контроллер единственная точка, где ты вошёл и вышел. Где у тебя есть контроль над транзакцией.
Юра
Да я пару раз встречал долгие дебаги когда флашили менеджер где попало, мало того ещё и clear делали
Kirill
Ты не можешь знать кто и где зафлашит. Контроллер единственная точка, где ты вошёл и вышел. Где у тебя есть контроль над транзакцией.
за запись должен отвечать сервис, который отвечает за какую-либо запись
Kirill
ну по логике
The Ant
Сервис может вызывать другой сервис, в том числе опосредовано через ивенты
The Ant
Юзкейс тоже самое, может другие юзкейсы юзать
Kirill
ну по-хорошему, эвенты не должны вызывать скрвисы)
Kirill
для этого всё же есть команды
Михаил
Флашить можно реально в контроллерах или в message handler-ах (я конечно так не делаю)
Тогда репозитории реально будут тупо делать persist
а то users->add($user, flush: true); выглядит каким-то костылём и у нас получается какой-то active record (обновил и тут же зафлашил)
аделать users->add($user); users->save(); это или раскрытие деталей реализации или бог весь что.
Флашить в юзкейсах с одной стороны странно, но с другой стороны почему бы и нет. Юзкейс это 1 единица работы, почему бы не флашнуть в конце)
Shokha
Ты не можешь знать кто и где зафлашит. Контроллер единственная точка, где ты вошёл и вышел. Где у тебя есть контроль над транзакцией.
разве для одного контроллера(action) не один сервис?
The Ant
Флашить можно реально в контроллерах или в message handler-ах (я конечно так не делаю)
Тогда репозитории реально будут тупо делать persist
а то users->add($user, flush: true); выглядит каким-то костылём и у нас получается какой-то active record (обновил и тут же зафлашил)
аделать users->add($user); users->save(); это или раскрытие деталей реализации или бог весь что.
Флашить в юзкейсах с одной стороны странно, но с другой стороны почему бы и нет. Юзкейс это 1 единица работы, почему бы не флашнуть в конце)
Юзкейс может юзать другой юзкейс. Например у тебя есть редактирование поста. С ивентами со всякой фигнёй. И это юзкейс. И есть множественное редактирование постов. Где ты в цикле запускаешь редактирование по одному.
Михаил
Юзкейс может юзать другой юзкейс. Например у тебя есть редактирование поста. С ивентами со всякой фигнёй. И это юзкейс. И есть множественное редактирование постов. Где ты в цикле запускаешь редактирование по одному.
ну в цикле юзкейсы - это ты или бд заебёшь или по памяти вылетишь
Михаил
Но я говорю - если считать что юзкейс это одна единица работы, то флаш пригоден
The Ant
ну в цикле юзкейсы - это ты или бд заебёшь или по памяти вылетишь
Альтернативы? Придется дублировать логику для редактирования постов
Михаил
можно сделать собственную обёртку над флашем который не делает это слишком часто, но звучит как бред и неконтролируемо
Михаил
Альтернативы? Придется дублировать логику для редактирования постов
да нет альтернативы. Везде есть плюсы и минусы
Сергей
Альтернативы? Придется дублировать логику для редактирования постов
юзкейс вызывать из юзкейса - это какое-то говно не правильно.
юзкейс у тебя дергает домен с его логикой и доменными событиями. А в конце флашит.
Либо дергает сервис, который что-то вычисляет.
В твоем примере про множественное редактирование, юзкейс вызывает update у домена Post, внутри которого вызываются все необходимые доменные события, которые обрабатываются после флаша
The Ant
юзкейс вызывать из юзкейса - это какое-то говно не правильно.
юзкейс у тебя дергает домен с его логикой и доменными событиями. А в конце флашит.
Либо дергает сервис, который что-то вычисляет.
В твоем примере про множественное редактирование, юзкейс вызывает update у домена Post, внутри которого вызываются все необходимые доменные события, которые обрабатываются после флаша
В таком случае юзкейс не имеет смысла, если его задача вызвать один другой сервис. Этот сервис можно вызвать прямо в контроллере.
Обычно в юзкейсе есть ещё всякие действия.
Сергей
В таком случае юзкейс не имеет смысла, если его задача вызвать один другой сервис. Этот сервис можно вызвать прямо в контроллере.
Обычно в юзкейсе есть ещё всякие действия.
контроллер - это эндпоинт. У тебя эндпоинтов может быть много разных - консольные команды, графкуэль, контроллеры, консумеры.
Для этого юзкейсы и нужны, чтобы их можно было вызывать из разных мест.
Их задача - принять входящие данные, получить сущности из базы, как-то их изменить и далее сохранить изменения.
Задача контроллера - получить данные, подготовить их для юзкейса (провалидировать), и вызвать юзкейс, отдать ответ.
Сергей
В таком случае юзкейс не имеет смысла, если его задача вызвать один другой сервис. Этот сервис можно вызвать прямо в контроллере.
Обычно в юзкейсе есть ещё всякие действия.
не , ну действия то можно добавить. Диспатчить что-то, в очередь кидать то, что мимо доменных событий и т.д. Но в большинстве случаев ты этого не делаешь.
Поэтому и дублирование логики у похожих юзкейсов как правило не происходит
Владимир
Юзкейс может юзать другой юзкейс. Например у тебя есть редактирование поста. С ивентами со всякой фигнёй. И это юзкейс. И есть множественное редактирование постов. Где ты в цикле запускаешь редактирование по одному.
А чем редактирование одного поста отличается от редактирования множества постов?
В плане
editPosts(editPostDTOList)
И в лист ты просто передаешь 1 пост :)
The Ant
🤷♂
Юра
Ну вот я тоже думал про сервис под юзкейс, но это какое-то третье усложнение мне кажется по каждый эндпоинт нужен такой сервис, проще уже флаш в контроллер добавить
Сергей
Нужно мне добавить айдишник в сущность и сделать его foreign-кеем.
можно ли это как-то сделать без рилейшнов?
Юра
Народ нужен ваш совет. Хочу МР фичи сделать в симфу. В чем смысл. Есть атрибут MapRequestPayload. Симфа умеет смапить данные в ДТО автоматически. Но я хотел бы залогировать результат мапинга. Идея добавить в RequestPayloadValueResolver логер и залогировать результат мапинга перед валидацией.
Юра
Я пробовал сделать листенер чтобы залогировать, все ок, но если данные не валидные мой листенер не вызывается
Юра
А если мой листенер будет срабатывать до встроенного мапера, тогда я не получаю результат и не могу залогировать
Юра
Может есть способ как-то сделать это по другому
Login
https://www.youtube.com/watch?v=SycSx0Qp3eg
Спасибо большое.
вот вам, может кому то будет полезно....
https://youtu.be/apVlDI_pWuk?list=PLxUDM49DgcpCD0m7sE-K7POzTHCRY-f0d
Dmitriy
Может есть способ как-то сделать это по другому
Не использовать MapRequestPayload, он достаточно хреновый, вместо него использовать ValueResolverInterface
Михаил
Может есть способ как-то сделать это по другому
Создай ишшью и спроси там. Mr - шляпа полная как на деле оказалось, ValueResolver гораздо гибче
Павел
ну в контроллерах - это изврат полный)))
Был крайне удивлен, но в https://t.me/oop_ru был не один человек, кто в целом не против контроллеров в этом вопросе и идею "не загасили".
Но там было одно "но", у них не было апликейшен слоя, что тоже "вот это поворот" и оказалось нормальным на просторах архитектурных обсуждений. И получается если нет этого слоя, он автоматом в контроллере и почти одно и тоже флаш внутри сервиса.
Kirill
ну так-то да, в том же ADR вообще как бы никаких слоёв)