третья сущность - например?

третья сущность - например?

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

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

В качестве наброса: команда - часть домена

ну вообще так и есть

потому команды можно прокидывать в сущности)

ну вообще так и есть

Да, но почему-то данная концепция сложно идет :)

Да, но почему-то данная концепция сложно идет :)

да, умом понимаю, что оно так, но чуть коробит)

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

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

пока еще вот такой вариант в голове крутится: приватный метод update, принимающий nullable аргументы для всех полей класса (если аргумент null - не обновляем его), и несколько методов updateFrom(....), принимающих дто/команду выглядит не очень хорошо с точки зрения srp с другой стороны - достаточно гибко + изолированный круд (иногда, к сожалению, круда не избежать)

пока еще вот такой вариант в голове крутится: приватный метод update, принимающий nullable аргументы для всех полей класса (если аргумент null - не обновляем его), и несколько методов updateFrom(....), принимающих дто/команду выглядит не очень хорошо с точки зрения srp с другой стороны - достаточно гибко + изолированный круд (иногда, к сожалению, круда не избежать)

null это путь к боли

пока еще вот такой вариант в голове крутится: приватный метод update, принимающий nullable аргументы для всех полей класса (если аргумент null - не обновляем его), и несколько методов updateFrom(....), принимающих дто/команду выглядит не очень хорошо с точки зрения srp с другой стороны - достаточно гибко + изолированный круд (иногда, к сожалению, круда не избежать)

Круд это не что-то, что надо избегать. Просто надо понимать где круд, а где нет)

я скорее про "круд vs поведение" и про то, что я не могу, как недавно Сергей расписывал, делать отдельно метод вроде "deactivate"

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

Парни, крч есть стратегия. Стратегия юзает гейтвей для доступа к апи внешнего сервиса. Все это клево работает через DI (гейтвей инжектится в стратегию, у каждой стратегии по гейтвею) и маппинг зависимостей через сервис контейнер. Но появился еще один гейтвей, который имплементит дополнительный функционал через сторонний внешний сервис. И у каждой стратегии такой гейтвей может как быть, так и нет. Хочется оставить зависимость стратегия->гейтвей унифицированной для каждой стратегии, как мне тогда инжектить дополнительный гейтвей?

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

т.е. имеем следующее: у каждой стратегии гарантированно есть один гейтвей и негарантированно есть дополнительный гейтвей

и на каком уровне внедрять этот дополнительный гейтвей непонятно - на уровне сервис локатора, либо просто в конструкторе стратегии делать additionalGateway = new Gateway

и на каком уровне внедрять этот дополнительный гейтвей непонятно - на уровне сервис локатора, либо просто в конструкторе стратегии делать additionalGateway = new Gateway

сервис локатор откуда взялся?

из фреймворка)

у тебя ж DI

инджекти каждой стратегии те гейтвеи и столько сколько надо

ну да, DI + SL

инджекти каждой стратегии те гейтвеи и столько сколько надо

а если появится 3 гейтвей?

4, 5

ну будет 3,4 5 гейтвеев

ну... Ладно)

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

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

ну я хз почему у тебя вообще 2 гейтвея появилось

либо не все из них юзается в пределах стратегии (и тога накой инджектить то что не юзается) либо ты зря разделил либо стратегии твои не совсем стратегии

хер знает короч

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

не, стратегии именно что стратегии, 2 гейтвей появился, потому что нужен доступ к функционалу стороннего сервиса. Типо был сначала гейтвей для одного АПИ, но решили некоторый функционал брать из другого АПИ (итоговая роль стратегии не поменялась при этом)

в общем декомпозировали доступ к внешнему сервису на 2 апишки разных, в угоду более простой имплементации функционала

не, стратегии именно что стратегии, 2 гейтвей появился, потому что нужен доступ к функционалу стороннего сервиса. Типо был сначала гейтвей для одного АПИ, но решили некоторый функционал брать из другого АПИ (итоговая роль стратегии не поменялась при этом)

два варианта - либо инджекти оба гейтвея либо сделай фасад если так не удобно

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

Хмм. Фасад может подойти кстати

Спасибо Сергей

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

излишняя абстракция ведь зло

https://segment.com/blog/goodbye-microservices/

https://segment.com/blog/goodbye-microservices/

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

или типа надо почитать а не делать выводы по заголовкам

Мне кажется что в статье происходит подмена понятий

ну на половине непонятно, к чему они ведут

рассказывают про путь своих фейлов

Микросервис != deployment target

угу, rules engines вспоминается

А у нее монолит это когда монореп

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

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

и как бы делать снепшоты трафика... а обновлять их кто будет?

главный посыл имхо - "подумайте, прежде чем делить все"

ну и вот этот пункт закрывается тестами > Updating the version of a dependency may break multiple destinations

https://segment.com/blog/goodbye-microservices/

Очень забавно что мне этот блог пост рекламировался в твиттере

ну и вот этот пункт закрывается тестами > Updating the version of a dependency may break multiple destinations

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

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

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

про deployment target, да

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

в целом не сложно

https://github.com/unravelin/tomono - можно вот такими штуками а уже потом оптимизировать под процессы

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

зачем?

ERROR: S client not available

зачем?

гугли разбирайся)

эмм

вопрос то конкретно к вам, зачем вам монореп

я ж не могу загуглить "зачем Сергею Протько монореп"

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

почему - гугли почему вообще люди переходят с мультиреп на монорепы

в целом 80% статьи выше о этих проблемах

но если коротко - общая инфраструктура

сколько у вас реп сейчас?

сколько у вас реп сейчас?

не оч много, штук 8-9

Омг, жоско

Я просто даже до такого не переходил, сразу перешёл к монорепе, пару месяцев назад описывал тут как то свой опыт)

С монорепами довольно много своих проблем, но это однозначно лучше чем 9 реп ?

я ж не могу загуглить "зачем Сергею Протько монореп"

нагуглил уже что-нибудь?

нет

я вообще работаю

https://mail.python.org/pipermail/python-committers/2018-July/005664.html

Новость для пятницы 13

вчера в питоночате уже обсудили

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

имхо - без BDFL будет намного хаоса, а потом все станет ок

Да pep вроде нормальный

ну многие не оценили

Вообще интересно как организуется сообщество питонщиков

Вообще интересно как организуется сообщество питонщиков

хреново

https://wiki.python.org/moin/AlternateLambdaSyntax

If Guido doesn't like it, it ain't gonna happen!

просто показатель

If Guido doesn't like it, it ain't gonna happen!

уже такого не будет)

ну вот и славненько)

Так ну это и интересно)