А почему создавать две? Почему мы не можем определить всю эту логику внутри метода получения Юзера?

потому что охренеешь потом поддерживать это

Либо же сделать два метода, например

а потом вы захотели хранить не в mysql, а pg. Еще метод + менять во всех местах

Мне лень приводить пример, потому что в три строчки он не уместится, и даже в тридцать строчек тоже скорее всего не получится уместить.

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

а потом вы захотели хранить не в mysql, а pg. Еще метод + менять во всех местах

Окей, ну вот все скрываем значит за методом Get/Create

Нас в принципе не волнует откуда и как оно получает

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

угомонись уже. В тебе дружно признали крутого архитектора. Довольно

Окей, ну вот все скрываем значит за методом Get/Create

а тестировать как?

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

Это правда, но давайте снизим градус

Окей, ну вот все скрываем значит за методом Get/Create

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

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

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

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

Простите, Pawel, я уже описал, а то что моё описание для вас непонятно - это уже боюсь не моя вина.

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

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

Ну, вот тут возможно проблема

Нас в принципе не волнует откуда и как оно получает

хорошо. ты с некоторыми оговорками описал репозиторий

хорошо. ты с некоторыми оговорками описал репозиторий

Странно, реализации то вроде как разные

Ну, вот тут возможно проблема

Вот, польза репозитория как раз в том, что бы абстрагировать работу с данными (условно get/set) от конкретной реализации этой работы (redis-get, redis-set)

Странно, реализации то вроде как разные

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

Странно, реализации то вроде как разные

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

Ну, вот тут возможно проблема

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

Я вот часто видел что в структуру репозитория пихают бд. Верно?

чтением у тебя в примере занимается репозиторий, а запись почему-то ответственность сущности.

Это правда, но давайте снизим градус

Заметьте, я не плююсь и не даю ни кому оценок в отличие от. Просто интересно как они это пытаются объяснить.это смешно же

Я вот часто видел что в структуру репозитория пихают бд. Верно?

да

да

Окей. Как в этом случае обстоят дела с транзакциями?

Окей. Как в этом случае обстоят дела с транзакциями?

а что с ними?

Заметьте, я не плююсь и не даю ни кому оценок в отличие от. Просто интересно как они это пытаются объяснить.это смешно же

Обычно я тоже стараюсь не давать оценок. Но тут уж не сдержался, слишком вопиющий случай.

Допустим транзакция вида: создаём сообщение, обновляем счетчик сообщений.

Как это будет организовано через репозитории?

в репозитории просто этого быть не должно)

Не должно быть чего? Транзакций?

ровно как и создания чего-либо

Как это будет организовано через репозитории?

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

А почему создавать две? Почему мы не можем определить всю эту логику внутри метода получения Юзера?

потому что код пишут много людей и требуется проводить границы между командами одни могут заниматься логикой - взаимодейтсвием пользователей друг с другом другие - сохранением даных чтобы не видеть файл user.go на 5к строк в котором будет перемешано и работа с БД и с кешем и запросы в third-party и логика приложения и используют абстракции

там выше накидывали за cqrs. очень в цвет накидывали

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

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

там выше накидывали за cqrs. очень в цвет накидывали

cqrs - архитектурный паттерн, который позволяет разделить чтение и запись. Жить станет чуточку проще, ровно как и код организовывать.

cqrs - архитектурный паттерн, который позволяет разделить чтение и запись. Жить станет чуточку проще, ровно как и код организовывать.

с cqrs жить становится сложнее, это больше вынужденная мера

с cqrs жить становится сложнее, это больше вынужденная мера

Только когда начинаешь втягиваться, как и с любым подходом.

Только когда начинаешь втягиваться, как и с любым подходом.

втягиваться?

втягиваться?

понимать, если угодно.

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

но это никак не упрощает саму разработку

и поддержку

как cqrs относится к тому, что ты написал?

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

он тоже усложняет код

он тоже усложняет код

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

блин... вы тут на наркоте что ли сидите

ну он-то усложняет, да но я лично не хочу писать в процедурном стиле даже на простейших проектах

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

если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?

он тоже усложняет код

Чем сложнее тем лучше, разве вы ещё не поняли?)

обработка ошибок усложняет код

обработка ошибок усложняет код

не утрируйте

если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?

сегодня их три, завтра их 33

сегодня их три, завтра их 33

и вот тогда и появятся репозитории

рефакториг никто не отменял

и вот тогда и появятся репозитории

дакси (ой это с греческого хорошо), не панацея

нет, правда, гораздо проще же везде делать panic(err), а в мейне один обработчик паники ?

нет, правда, гораздо проще же везде делать panic(err), а в мейне один обработчик паники ?

Обработчик паники в мэйне бесполезен. Учите го ))

если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?

если тебе придется что-то в нем менять - то будет полезно

спасибо за ценный совет, пора мне перестать пукать в этом чате

Кстати, такой вопрос по логированию: я так понимаю что хоший подход инициализировать БД, логгер и прочее в мейне и потом пробрасывать это все через уровни. Вот мы на уровне бизнес логики, и у нас идёт обращение к БД через какой то метод. Где мы должны логировать – на уровне обращения к БД либо на уровне бизнес логики ?

Заранее извиняюсь если сумбурно

Более того, панику вообще не надо обрабатывать. Любителям репозиториев на заметку

Более того, панику вообще не надо обрабатывать. Любителям репозиториев на заметку

зависит от ситуации

вы видите те же слова, что и я?

ERROR: S client not available

Кстати, такой вопрос по логированию: я так понимаю что хоший подход инициализировать БД, логгер и прочее в мейне и потом пробрасывать это все через уровни. Вот мы на уровне бизнес логики, и у нас идёт обращение к БД через какой то метод. Где мы должны логировать – на уровне обращения к БД либо на уровне бизнес логики ?

бизнесс логика ничего не знает про базу и логгер. Это инфраструктура

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

зависит от ситуации

Оч редко Пару раз в жизни

бизнесс логика ничего не знает про базу и логгер. Это инфраструктура

Ну вы ведь явно пробросите их как параметры. Либо же объявите на цровне пакетов?

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

Окей. Тогда какой подход выберете вы?

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

чем плох логгер в бизнес-логике? 0о

чем плох логгер в бизнес-логике? 0о

а чем плох коннект к бд?)

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

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

.....иииии?

тот же ответ и логгеру

но ведь в бизнес-логике требуется логирование

Так где Логировать?

бизнесс логике логирование зачем? приведи пример

не запросов к базе, но вещей связанных с бизнес-логикой

бизнесс логике логирование зачем? приведи пример

Ну вот надо, хотят что то логировать

Ну вот надо, хотят что то логировать

ну, пускай логируют. Но почему это задача домена?)

ну, пускай логируют. Но почему это задача домена?)

Тогда где это делать?

Ну вот мы хотим логировать что то из домена

Где нам это делать

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

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

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

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

такс... погоди) уровень домена - что в этом случае? конкретнее.

такс... погоди) уровень домена - что в этом случае? конкретнее.

Бизнес логика

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

Ну вот Logic tier

на adr смахивает

ну т.е. Logic tier у нас умеет принимать запросы, как-то их крутить, ходить за данными и давать указание на построение проекций?

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

Что вы понимаете под доменом?