А если суть быть бизнес сущностью, то ей не надо на фронт. Поэтому сериалайзеры ваши - ненужная вещь.

так на response да можно и без него, а вот на request использовать serializer удобно же.

так на response да можно и без него, а вот на request использовать serializer удобно же.

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

Речь вероятно про реквест боди, в котором json

дело в том, что для сущностей нельзя вызывать конструктор вне сценария создания сущности а для команд как раз конструктор самое то

какие данные? Я про данные,что то говорил? Вот тебе пример как инстанцируется serializer.

ужасть... говорю же: руки за такое отрубить могут по самую шею... https://github.com/symfony/symfony/blob/60ce5a3dfbd90fad60cd39fcb3d7bf7888a48659/src/Symfony/Component/Serializer/Normalizer/MimeMessageNormalizer.php#L48 в $this->serializer пишем SerializerInterface смотрим его методы (https://github.com/symfony/symfony/blob/60ce5a3dfbd90fad60cd39fcb3d7bf7888a48659/src/Symfony/Component/Serializer/SerializerInterface.php): serialize() и deserialize() круть смотрим дальше наш MimeMessageNormalizer: https://github.com/symfony/symfony/blob/60ce5a3dfbd90fad60cd39fcb3d7bf7888a48659/src/Symfony/Component/Serializer/Normalizer/MimeMessageNormalizer.php#L60 чаго??? откуда у SerializerInterface метод normalize появился??? если я там засеттю только SerializerInterface, у меня код упадет и не по моей вине, на самом деле причем я открыл сначала в 5.4, там кучу таких косяк нашел, стал смотреть на гитхабе, а большую часть уже исправили пришлось искать в 6.0 и нашел а все почему? потому что понамешано дофига и больше причем я уже здесь писал про косяки симфони, когда они явно использовали компонент, указанный в зависимости своей зависимости это в ошибку вылилось, а значит "симфони так делает" не показатель )) вангую придет день, когда и в сериалайзерах грохнут это спагетти

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

Только не говори что для ДДД лучше делать на GO чем на PHP)))

$data = ['id' => $id] + $request->toArray(); $this->dispatchMessage(new Update\Command(...$data));

Только не говори что для ДДД лучше делать на GO чем на PHP)))

Лучше/хуже странная оценка. В ддд каждый контекст может быть микросервисом на своем языке, никто не запрещает.

Лучше/хуже странная оценка. В ддд каждый контекст может быть микросервисом на своем языке, никто не запрещает.

Я к тому что без вменяемого ООП, реализовывать паттерны ДДД такое себе)))

$data = ['id' => $id] + $request->toArray(); $this->dispatchMessage(new Update\Command(...$data));

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

так что из двух этих я бы выбрал Php )

Я к тому что без вменяемого ООП, реализовывать паттерны ДДД такое себе)))

о, паттерны ддд, интересно

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

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

Ну че вы ерничаете. вы прекрасно меня поняли

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

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

Направление мысли понятно было, нормальных реализаций не встречал просто. Ваша выглядит хорошо, надо попробовать на развесистых моделях.

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

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

Ну че вы ерничаете. вы прекрасно меня поняли

Вам в го ооп не нравится, из своих предпочтений вы выводы делаете. Не понятно на что вы рассчитываете кроме сарказма. Есть апи, в нем отдается структура с большой вложенностью, нагрузка 9кк хитов в сутки. На пхп придется попрощаться с ооп и типизацией. В контекстах оно там лежит или еще как - это уже не важно, когда вы на 20 лет назад возвращаетесь.

Вам в го ооп не нравится, из своих предпочтений вы выводы делаете. Не понятно на что вы рассчитываете кроме сарказма. Есть апи, в нем отдается структура с большой вложенностью, нагрузка 9кк хитов в сутки. На пхп придется попрощаться с ооп и типизацией. В контекстах оно там лежит или еще как - это уже не важно, когда вы на 20 лет назад возвращаетесь.

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

вы правы конечно, но и ддд не является панацеей

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

Вам в го ооп не нравится, из своих предпочтений вы выводы делаете. Не понятно на что вы рассчитываете кроме сарказма. Есть апи, в нем отдается структура с большой вложенностью, нагрузка 9кк хитов в сутки. На пхп придется попрощаться с ооп и типизацией. В контекстах оно там лежит или еще как - это уже не важно, когда вы на 20 лет назад возвращаетесь.

Ну скажем так, "отдаваться" то может у вас чем угодно, хоть и go если у вас там rps зашкаливает. В моей картине мира ДДД это вообще не про "отдаваться". Тут как раз вспонимали про CQRS. А вот описывать залихватскую бизнес-логику изменящую агрегаты в GO, ну хз. Может я не сильно большой спец в нем, но я бы там потонул потом в этом коде. К тому же, в вашем случае может и DDD никчему. Основной мой опыт хитрые бизнес-системы, где rps на запись не большой, а вот всяких путанных хотелок воплощенных в коде дохрена

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

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

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

Не удобно. Как минимум теряем поддержку Discriminator map, плюс вложены объекты расскидывать руками ну такое

Не удобно. Как минимум теряем поддержку Discriminator map, плюс вложены объекты расскидывать руками ну такое

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

Кто то подружил сонату на 5м симфони с ckeditor?

V

Всем привет. Может быть кто то сталкивался. У меня есть очередь order_messages со стратегией max_retries: 5 delay: 5000 так же для нее есть failure_transport: failed_order_messages который является тоже очередью с отдельным хендлером. В случае ошибки order_messages я выкидываю throw new \Exception() в хендлере order_messages, но failed_order_messages отрабатывает при первом ретрае а не после всех попыток доставить сообщение. Буду рад если подскажите в кукую сторону копать )

Думаю копать в сторону xdebug куда-то

)

Думаю копать в сторону xdebug куда-то

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

Да должен уходить в ретрай

У меня уходил

Я наоборот убирал ретрай у себя

вот он не уходит... уже чего только не пробовали. Один раз отрабатывает и сразу в failed транспорт.

Я наоборот убирал ретрай у себя

а почему убирал? кастомный ретрай алгоритм?

retry_strategy: max_retries: 0

Я хочу выстроить логику т.о. чтобы после отработки стратегии ретраев, сообщение перекладывалось в другую очередь, которую будет обрабатывать другой хендлер

ну так надо сделать фейл транспорт

мне просто не нужен фейл транспорт

http://joxi.ru/l2ZOJ7lul8K5DA Получается что сообщение old_pc_reserve_messages обрабатывает 2 хендлера

А

Ну так роутинг не нужен

Поэтому оно туда попадает сразу

Почитай доку

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

Тогда такой вопрос могу я в хендлере узнать сколько раз это сообщение пыталось доставиться?

и просто отловить его на последней попытке?

https://symfony.com/doc/current/messenger.html#manually-configuring-handlers

так то оно настраивается конечно

Спасибо буду изучать

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

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

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

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

Это все так и работает

Почитай доку

В твоем конфиги лишний роутинг

В твоем конфиги лишний роутинг

не, у него там хендлер добавлен в роутинг он не лишний, он просто неправильно добавлен

Если я проверяю bin/console debug:messenger то на одно сообщение получается 2 хендлера App\Message\OldPCMessages\OldPCReserveMessage handled by App\MessageHandler\FailureTransport\FailedOldPCReserveMessagesHandler handled by App\MessageHandler\OldPCMessageHandlers\OldPCReserveMessageHandler

Потому что failed не нужен в роутинге

Блин ну епрст. Говорю почитай доку

Там есть про ретрай

А мож я туплю

Я это читал) Все что не долетело попадает в бд. php bin/console messenger:failed:retry отпавляет все это чудо по второму кругу. а вот новый обраточик для этих упавших сообщений как назначить, я хз

Я это читал) Все что не долетело попадает в бд. php bin/console messenger:failed:retry отпавляет все это чудо по второму кругу. а вот новый обраточик для этих упавших сообщений как назначить, я хз

Думаю это то что тебе нужно

Спасибо, все нашел)

Посоветуйте пожалуйста: мне надо что-то типа журналирования некоторых данных: кто изменил, когда изменил, что изменил, на что изменил. На чем такое проворачивать? Elk? Или что-то другое?

Мне не кажется, что хранить такое в основной базе хорошая идея

Мне не кажется, что хранить такое в основной базе хорошая идея

Почему?

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

Но наверняка захочется фильтровать это потом

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

Когда как, created_at, updated_at и тд

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

Вроде как не особо такая структурность нужна