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

но суть не в конкретном случае

а в чём?) в нейминге метода?

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

хотя скорее

это выбор между change или update и setFoo, setBar, setBaz

change, имхо, от setX не особо отличается

change, имхо, от setX не особо отличается

вот я потому вопрос и задаю

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

У меня новый блог пост, о том как быть, если проблема слишком сложная, а времени мало: http://www.yegor256.com/2018/04/17/how-to-be-lazy.html

т.к. она в дальнейшем разделении сущностей

ну ты либо клешнями всё делаешь "как надо", либо как-то автоматически (читай, через setX)

ну ты либо клешнями всё делаешь "как надо", либо как-то автоматически (читай, через setX)

что имеешь ввиду под "клешнями"?

в смысле берёшь дтошку с формочкой и маппишь её ручками прям красиво

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

ну обработчик принимает команду и "раскладывает" всё по методам) ну или не парясь рефлексией забивает)

как бы пихать в сущность штуку типа updateFromCommand - фи

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

рефлексия тут - явно треш)

вариант от балды, сам понимаешь)

по вашему мнению, корректно ли использовать методы вроде $foo->change($firstName, $lastName, $email, $phone) для штук вроде обработчика формы редактирования (утрированно)?

лучше заменить на VO

change(Profile::new(firstName, lastName, bla, bla)

так я VO и изменяю...

точнее, embedded

у него просто пример некорректный)

так я VO и изменяю...

VO нельзя изменить

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

в этом плане change твой вполне валидный

про иммутабельность подумаю, точно

в этом плане change твой вполне валидный

ну и главное - вернуть новый

ну и главное - вернуть новый

конечно, это будет как именованный конструктор)

осталось подумать, почему embedded сущность должна быть vo

потому что embedded не сущность?)

потому что embedded это именно ВО?

если сомневаешься - просто попробуй изменить поле в VO

UoW не задетектит изменений (хотя тут не уверен)))

ай тьфу

голова не ворочает

это не embedded просто связанные сущности

но по сути - композиция

contact data, используется ещё в трех сущностях

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

грокаем алгоритмы

если сомневаешься - просто попробуй изменить поле в VO

Дядя Эванс завещал что низя такое делать)

Ымутабылыти

Дядя Эванс завещал что низя такое делать)

то мой бредик, забей)

голова не варит и называю штуки не их именами

голова не варит и называю штуки не их именами

Это у всех бывает)

Ребята, привет, наставьте меня на путь истинный! Пишу клиентов для внешних АПИ. Их много и все разные, очень часто встречается "антипатерн" когда апи отвечает с ошибкой, отказом, просит повторить запрос чуть позже. разраб который был до меня не парился в коде либы делал в каждом методе public finction getById() { while(true) { ... sleep($s); ... } } , надо ли говорить сколько муки с таким кодом. собственно я вычистил все либы от этих while и sleep, но теперь вопрос куда лучше поместить эту логику перезапросов? просто перемещением в клиента библиотеки лучше не становится, от перемены слагаемых местами сумма не изменяется... вот думаю может между клиентом и библиотеками сделать фасад или прокси по GoF? или какие есть хорошие практики решения таких задач?

есть нехорошая практика типа Phystrix, но она не спасет полностью

Ребята, привет, наставьте меня на путь истинный! Пишу клиентов для внешних АПИ. Их много и все разные, очень часто встречается "антипатерн" когда апи отвечает с ошибкой, отказом, просит повторить запрос чуть позже. разраб который был до меня не парился в коде либы делал в каждом методе public finction getById() { while(true) { ... sleep($s); ... } } , надо ли говорить сколько муки с таким кодом. собственно я вычистил все либы от этих while и sleep, но теперь вопрос куда лучше поместить эту логику перезапросов? просто перемещением в клиента библиотеки лучше не становится, от перемены слагаемых местами сумма не изменяется... вот думаю может между клиентом и библиотеками сделать фасад или прокси по GoF? или какие есть хорошие практики решения таких задач?

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

Ребята, привет, наставьте меня на путь истинный! Пишу клиентов для внешних АПИ. Их много и все разные, очень часто встречается "антипатерн" когда апи отвечает с ошибкой, отказом, просит повторить запрос чуть позже. разраб который был до меня не парился в коде либы делал в каждом методе public finction getById() { while(true) { ... sleep($s); ... } } , надо ли говорить сколько муки с таким кодом. собственно я вычистил все либы от этих while и sleep, но теперь вопрос куда лучше поместить эту логику перезапросов? просто перемещением в клиента библиотеки лучше не становится, от перемены слагаемых местами сумма не изменяется... вот думаю может между клиентом и библиотеками сделать фасад или прокси по GoF? или какие есть хорошие практики решения таких задач?

я так понимаю все запросы синхронные?

синхронные

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

и ко всем запросам

должна ли логика приложения управлять стратегией перезапросов?

имхо общего простого решения нету

ну зависит

у всех апи/методдов разнаая логика для понимания необходимости перезапроса

у разных API будут разнче критерии "фатальная ошибка или можно повторить запрос"

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

а это какой-то пхп-скрипт-по-крону?

т.е. сейчас копипасты очень много

или вебморда?

это в реалтайме

веб

у всех апи/методдов разнаая логика для понимания необходимости перезапроса

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

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

ну типа result = fooClient.doBar(arg1, arg2, new RetryTimes(3))

таки хочется это вынести в отдельную сущность для упрощения

если таки веб, то phystix может помочь... ну или концепцию оттуда взять

там комманд-паттерн днище и еще донные зависимости от зенд-di

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

есть фолбеки и т.д.

(но я бы для своего проекта свой написал)

в более общем случае где-то в DIC можно делать как-то так new FooClient(new HttpClient(new RetryStrategy()))

в более общем случае где-то в DIC можно делать как-то так new FooClient(new HttpClient(new RetryStrategy()))

какая страшная жава

какая страшная жава

псевдокод

я не о синтаксисе

я не о синтаксисе

то есть так делать не надо?

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

class Api { request() } class RetryDecorator { construct(private api: Api) {} request() { // call this.api.request() and retry on failure } }

да, с декоратором будет красивше

ещё есть http клиенты с поддержкой middleware и там уже всё готовое: https://github.com/guzzle/guzzle/blob/master/src/RetryMiddleware.php

вот кстати гузле и используется...

вызывать реквест в мидлваре - это дно

не делайте так

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

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

выглядит неплохо: https://justcodeit.ru/povtornaya-otpravka-http-zaprosov-v-guzzle/

вообще, как по мне, то побеждают два решения: - декоратор (как самый быстрый и простой вариант) - то же самое, но без декоратора

декоратор, спасибо, попробую

выглядит неплохо: https://justcodeit.ru/povtornaya-otpravka-http-zaprosov-v-guzzle/

тоже в принципе норм

Вы решаете проблему не с того конца