@russophobe дал RO на неделю

русофоб? :)

не мало ли неделю?

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

ибо наша с Олегом - вполне себе понятно объясняет что есть что и плюсы и минусы. А твоя - ничего не проясняет вообще и только усложняет

Aleh это Олег?

Да

Как вы относитесь к многоуровневой реализации интерфейсов? Пример: У меня есть стратегия выбора Группы - GroupChoise Есть выбор группы рандомный и допустим по локации, вот два интерфейса, наследуют предыдущий(и все это относится к бизнесс логике) RandomGroupChoise и SomeAnotherLogicGroupChoise И вот уже у этих интерфейсов естьреализации в инфраструктурном слое: NativePhpRandomGroupChoise, SomeExternalServiceRandomGroupChoise и т.д

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

Вообще это нормально, видел статейку, как чувак автомат состояний на интерфейсах делал, и ниче - норм)

Как вы относитесь к многоуровневой реализации интерфейсов? Пример: У меня есть стратегия выбора Группы - GroupChoise Есть выбор группы рандомный и допустим по локации, вот два интерфейса, наследуют предыдущий(и все это относится к бизнесс логике) RandomGroupChoise и SomeAnotherLogicGroupChoise И вот уже у этих интерфейсов естьреализации в инфраструктурном слое: NativePhpRandomGroupChoise, SomeExternalServiceRandomGroupChoise и т.д

Бери язык с нормальными sum type и не канифоль себе голову интерфейсами

Aleh это Олег?

хыхы, откровения)

Бери язык с нормальными sum type и не канифоль себе голову интерфейсами

Я не выбираю язык, а он меня)

Пхп это призвание))

хыхы, откровения)

Я думал Алекс

Нет

Я не выбираю язык, а он меня)

Действительно, кто-то же должен поддерживать всё это легаси

Лучше пхп чем аниме

Действительно, кто-то же должен поддерживать всё это легаси

Я не жалуюсь

Бери язык с нормальными sum type и не канифоль себе голову интерфейсами

А что есть sum type?

А что есть sum type?

type sum = first | second | third ... Т.е такой тип который может быть любым из перечисленных типов, но не их комбинацией

Сумма потому что «размер» типа является суммой перечисленных типов

спс

Норм ли стратегия - в двух сервисах экосистемы делать разные миграции для одной БД?

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

они два сервиса и у них общая база?

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

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

Там есть общие таблицы, типо "users", "permissions"

а ты вынеси все что связано с пользователем в микросевис☺️

Решать проблему декомпозиции - еще большей декомпозицией?

Решать проблему декомпозиции - еще большей декомпозицией?

нууу... тип того

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

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

в четвертую хуйню выносить?

да

но! не всегда то что кажется одинаковым таковым является

а потому придумали правило трех для таких вещей

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

Эскобар одобряет

а потому придумали правило трех для таких вещей

?

?

rule of three (refactoring)

@fes0r а как бороться со связностью gateway <-> service? Где гейтвей это прослойка для рейтлимитов, сессий и т.п.

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

ERROR: S client not available

be one with the coupling (c) Udi Dahan

Подскажите пожалста: есть некий сервис который выписывает в сессию геолокационную всякую информацию. Есть несколько способов определения (если один из них находит инфу, найденное выписывается в сессию и дальше не идет), например: из базы внешней -> из локальной базы -> по локали браузера -> по дефолту. Оно и щас не страшно выглядит пока, но может есть паттерн какой подходящий под такую ситуацию который все это дело красиво разрулит, чтоб подкидывай\убавляй ему "определятели" и все?

Стратегия, не?

Да можт, я тут все примерно подходящее перечитал и сходу не решилось. Щас пересмотрю его, спасиб

Chain of Responsibility?

do { $resolver = array_shift($geoResolvers); if (($geoData = $resolver->resolve()) !== false) { return $geoData; } } while (count($geoResolvers) > 0); return false;

заполняешь array $geoResolvers инстансами интерфейса GeoResolver и запускаешь

Ага, примерно такое и планировалось в голове, спасибо.

у меня есть ORM который использует модели и есть репозиторий, который отдает DO как обычно называется объект, который из модели ORM делает DO для репозитория. или этим обычно занимается сам репозиторий?

у меня есть ORM который использует модели и есть репозиторий, который отдает DO как обычно называется объект, который из модели ORM делает DO для репозитория. или этим обычно занимается сам репозиторий?

Мэппер

Я тут задумался. А какая практическая польза делать свои эксепшены на каждый экшен. например publishPost($id). и эксепшен CantPublishAlreadyPublishedPost. может проще просто один какойнибудь ServiceLayerException и выбрасывать только его если что. только с разными message. Я всю жизнь создавал новый классы, но чтото сейчас задумался... а зачем?

Для многих catch например?

а зачем нам много catch? нам один раз поймать в одном месте все.. и нормально... там, выше, никому не интересно почему не получилось. не получилось и все.

Ну в зависимости от вылезшего обработать по разному)

да не надо по разному... ни разу не надо было

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

Я тут задумался. А какая практическая польза делать свои эксепшены на каждый экшен. например publishPost($id). и эксепшен CantPublishAlreadyPublishedPost. может проще просто один какойнибудь ServiceLayerException и выбрасывать только его если что. только с разными message. Я всю жизнь создавал новый классы, но чтото сейчас задумался... а зачем?

Да много плюсов есть. 1. Можно отлавливать события по разному. 2. Семантически верно - т.к это все таки разные события(экмпшны) 3. Для разных экспшнов разный набор полей может потребоваться 4. Для любителей строить иерархии, сохраняется возможность классификации экспшнов

ну это сходу

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