Чистая архитектура проекта на Golang
HTML-код
- Опубликовано: 23 сен 2023
- Мой курс по разработке микросервисов: clck.ru/389FM7
Репозиторий с примером: github.com/olezhek28/clean-ar...
Мой Boosty: boosty.to/olezhek28
Linkedin: / olezhek28
Telegram-канал: t.me/olezhek28go
В этом видео мы разберемся в основах создания архитектуры микросервисов на golang, познакомимся со слоистой архитектурой и реализуем DI-контейнер. Мы на практике поймем, как реализовать архитектуру go проекта, как в BigTech-компаниях. А также в конце я расскажу про свой курс по разработке микросервисов на golang.
Как же классно вас смотреть, все четко, по делу, без душноты)
Спасибо, приятно слышать:)
😁 Олег, респект! Отличный контент.
Спасибо большое)
Огонь, спасибо большое за полезную информацию!
рад, что понравилось)
Спасибо за труд!
Рад стараться:)
Олег молодец! Очень красноречив. Приятно слушать )
Спасибо:)))
Отличный урок, спасибо. То, что искал.
Рад, что понравилось:)
@@olezhek28go У меня один вопрос только появился только что.
Верно ли понимаю, что структуры одного уровня не должны использоваться друг другом? Иначе появляется риск зацикленности.
Пишу на C#, все выглядит похоже и знакомо. Правда, реализация интерфейсов в C# нравится мне больше.
Я тоже было время на шарпе чутка писал:) а что именно в интерфейсах нравится больше?
Лайк за разбор данной темы
Спасибо)
Спасибо за видео! Будучи джуниором уже пишу такой код :D *довольно понятно объясняете*
Отлично) Рад, что доступно изложил
такой материал в живой подаче очень приятно смотреть) спасибо! Сейчас прохожу отбор в Авито на стажировку, надеюсь там вас увидеть :)
спасибо за добрые слова) удачи в отборе!)
какой веселый чел, и презентации забавные делает) Повезло сохранить оптимизм )
Спасибо за добрые слова:)
🎉
Если у вас в микросервисе под 10 юзкейсов и реп и вам нужна DI-система, скорее всего у вас что-то не так пошло на этапе планирования микросервисной архитектуры)
Согласен:) скорее это бывает промежуточным состоянием, при котором принимаем решение распиливать:) а di лично мне на любых размерах кажется кайфовой штукой
лайк за разговорчики про архитектуру
Спасибо:)
Спасибо за видео. Блин, из-за того что в go нет возможности перечислять, какие интерфейсы должна имплементировать структура, как это сделано в других языках, приходятся делать такой костыль с переменной, то что структура удовлетворяет интерфейс -- это кек))))
Да это скорее удобство чтения добавляет) так-то можно и не писать такую конструкцию, просто ошибка на компиляции будет, а не сразу в ide
Привет, спасибо за контент, а стоит проходить курс, если в route256 обучался, в том числе у тебя)? И второй вопрос, на разборе будут показаны куски кода, как было бы правильнее реализовать или дана ссылка на реализацию от преподавателя текущего дз?)
Привет)
1) Если в руте на потоке где я обучал был, то наверное нового будет процентов 40. В целом по программе на сайте можешь оценить)
2) Я буду рассказывать темы, иллюстрируя примерами кода, которые будут доступны обучающимся. Что касается дз, то у меня тоже есть моя реализация, да
спасибо, вчера классно уснул в наушниках, придется пересматривать. Помню что повествование веселое, местами с шутечками, чувствуется что чел могёт ))
Спасибо за добрые слова:)
Ахахаха
Спасибо, очень понравилось. У меня возник такой вопрос, в чём состоит основное отличие чистой архитектуры от Слоистой архитектуры "Layered architecture" (N-layer). Например, почему представленный пример является чистой архитектурой, а не слоистой (N-layer), так как у меня возникла мысль (возможно неверная, прошу поправить, если это не так), что представленный пример можно было бы отнести к Слоистой архитектуре (N-layer).
Олег, отличный контент! Спасибо тебе! Небольшой вопрос: в коде модель репозитория и модель сервиса для User помещены в пакет model. Обе модели с публичной видимостью. В итоге к ним обеим можно обратиться как model.User, но при этом это разные структуры естественно. Возникает некоторая потенциальная путаница и необходимость пользоваться альясами. Это так и задумано? Или в конкретном случае лучше использовать разный нейминг/пакеты? Спасибо!
Спасибо за добрые слова) касательно вопроса - Мы на работе так и юзаем с алиасом) IDE сразу запоминает куда что ведет и импорты автоматом добавляются и путаницы фактически нет) но можно и разные нейминги попробовать)
@@olezhek28go Спасибо еще раз!
А верно ли, что сервисы на одном уровне/слое не должны использовать друг друга? Чтобы не происходило зацикливания.
А почему должно быть зацикливание? Это совершенно не обязательно)
Опа, новое от Козыря
так меня пожалуй с садика не называли)
Ток интерфейсы лучше в месте использования объявлять. Т.е. используешь в сервисе интерфейс репо, там его и объявляешь, указываешь какие методы твоему сервису нужны.
Иначе, если одному сервису нужны одни методы, а другому другие, и оба могут работать с одним и тем же репозиторием, то они будут эмбеддить интерфейс репозитория со ВСЕМИ его методами, а это избыточность и неудобство для программиста.
Я как раз говорил о холиварности этого вопроса) мы осознано выбрали варик как в видео и репо слой немного иначе разбивает, от того неудобства нет
@@olezhek28go Понял-принял.
@@olezhek28goинверсия зависимости направлена не в ту сторону. Бизнес логика зависит от репозитория и его импортирует.
для микросервиса покатит) но когда в приложении больше одного сервиса, то без слоя межсервисного взаимодействия будет .опа)
С несколькими еще жить можно, но чем дальше тем хуже, согласен)
На работе (python/fastapi) начали вводить чистую архетиктуру, интересно посмотреть на всю эту тему со слоями со стороны другого языка
И как в го проще или нет?
@@olezhek28go да трудно сказать, надо попробовать апиху полноценную выкатить, не хватает времени пока. У нас еще авторизация, орм, зависимостей внедрения свои способы. В fastapi уже есть это готовое, на коллектив можно опереться. А так со слоями нормально объяснили в видео -- делать их изолированными полностью, и все ок будет.
на больших бачах конвертер дорого юзать (ещё один проход O(n)), также спорно использовать конвертер на перекладывании одинаковых полей из одной структуры в другую. я лично предпочитаю сквозные дто/модели на микросервис.
прикол что ЧА разрабилась для модульных монолитов
ага, на большых бачах будет грустно( сквозные дтошки мы тоже юзали в другом проекте, сейчас решили иначе)
@@olezhek28go а что повлияло на выбор?
Олег а на собеседованиях DevOps/SRE в Ozon или Avito спрашивают алгоритмы или это только у разрабов?
Честно говоря не знаю, не интересовался на этот счет)
Возвращать интерфейс вместо структуры разве не антипаттерн?
А в чём проблема? Для этого же всё и задумывалось, чтоб абстракцией закрыться)
@@olezhek28go Интерфейса нужно положить туда, где этот интерфейс вызывается. А чтобы закрыть у нас есть инкапсуляция)
Как раз тут и случается срач по поводу интерфейсов:) Кто-то кладет по месту использования, кто-то иначе) так что стоит отталкиваться от того как договорились в комманде
@@olezhek28go так на выходе получаем какой-то конкретный объект, зачем нам возвращать абстракцию? чтобы использоваться полиморфизм, на вход мы получаем абстракцию, а на выходе зачем она непонятно
@@olezhek28goпроблема в том что это не конструктор сущности должен решать какие методы нужно реализовывать возвращать интерфейсом, а тот кто будет пользоваться должен определить нужный ему интерфейс для этой сущности. Конструктор возвращает конкретное(структура), потребители решают какие методы требуются (интерфейс)
А правда что в го можно новичкам идти? Непонятно что лучше взять питон или го?
Конечно можно) в чем проблема?)
Да, лучше питон в руках, чем гоу в кустах
эй.. почему не по схеме explicit architecture? ) один раз бы разобрались, было бы веселее )) А ещё DDD не хватат)
да я рассказывал из своей рабочей практики) а так-то конечно можно намутить будет как-нить урок веселья ради и по тому же DDD) Заодно будет повод лучше разобраться хех
@@olezhek28go это, я так понимаю, вся суть лучших практик по архитектуре - "веселья ради"? 😅
интересно когда-нибудь напишут для go Фреймворки, пока это выглядит, как ранний php, но хотя бы архитектурно придумали как делить это безобразие
Внутри крупных компаний есть:)
Надеюсь, что никогда
а разве было бы не прагматичнее convertor mapper'ом назвать?)
да в целом можно и так) тут скорее зависит как в команде договоришься) мы на конверторе сошлись)
вот говорит, что плюсами покусан, а сам пишет = (*repository)(nil) вместо = new(repository). Что-то тут не так...
Ну все, надо разоблачение снимать))
@@olezhek28go точно! И обязательно сдать своего диллера, который ключи от Goland'а поставляет ))
Сделайте поправочку только, что, это не та самая "чистая архитектура" как на первой картинке было
А обычная слоистая, трехзвенка в народе
Я уже не помню, что там за пикча была) в целом, если там шестиугольник, то кажется оно тут тоже ложится) или я что-то упускаю?
Посмотрел разные видосы по чистой архитектуре, единого стандарта тупо нет, каждый городит по своему "как удобнее или как понял" У кого-то Entity,Usecase у кого-то Model, Repository. Давайте еще какой-нибудь "Template" еще введем, чтоб всем дружно гадать, что это такое
Если правильно помню, я об это и говорил) в любом случае на уровне команды лучше устаканивать договоренности такие)
Не понял зачем RLock в гете.
Чтобы запись залочить)
@@olezhek28go пошёл читать доки сразу после просмотра, уже разобрался, спасибо)
А у кого-то есть пример цепной инициализации DB Client'a в контестке реализации, представленной в этом видео?
Дак а что там сверхъестественного?) принцип же тот же самый
Ну я столкнулся с некоторыми проблемами при попытке реализации, по этому решил спросить
Вопросы все задают вроде как все с опытом, но смотря как чувак распинается объясняя всем что он сделал все на интерфейсах, типа ООП, то понимаешь что многие вообще не знают что такое ООП, и инкапуляция в том числе.
Хотя Go он вообщето задуман как функциональный язык, и че городить ООП, я пока не догнал, за исключением "+" для поддержки проекта.
А закзчику тяжело с сайтом и сервером... дааа ерунда.
В Go коммьюнити вообще как-то странно с пониманием архитектуры сервисов, я заметил
@@JohnGraveв комьюните противостояние очкариков ушедших с плюсов и студентов после питона.
Борьба поколений!
Сорри, но 666 подписичков - пока кто-то не испортит, подписаться религия не позволит.
Уже испортили:(
Послушал первые 10 минут. Дальше не смог. Формулирование мыслей на уровне 5 класса.
А вы в шестой уже перешли?:)
Прикольно конечно, но я в ахуе с этих названий переменных: r, n, a, b, s. Для реального проекта это конечно будет тот еще пиздец, особенно когда новенькие придут и будут в этом разбираться
Это имена ресиверов и они как раз таки часто именно в таком стиле и задаются в проектах и проблемы в этом нет
@@olezhek28go Ну это в любом случае может ввести в некоторое заблуждение или недоумение неподготовленного человека, ничего не мешает написать название чуть подлиннее, зато любой человек поймет что к чему, да и легче потом в коде будет искать их использование
Таков стиль в гошке:) написать можно, спору нет
Все курсы и тренинги - вчерашний день, лохотрон) вы там получите как минимум устаревшую информацию) не рекламируйте это.. имейте совесть) в разы эффективней найти себе ментора) и дешевле и полезней
Почему я не могу рекламировать свой собственный курс, материал которого я обновляю) да и разговоры про знания, которые не используются тоже спорный) практики, которые я там рассказываю мы активно юзаем у себя в команде в Авито) ментор тоже хороший способ, спору нет
@@olezhek28go Если вы передаете свой опыт, знания и являетесь ментором для каждого ученика индивидуально - респект вам и уважуха.. если же нет - то те же пожелания наоборот вам.. и геморрой хронический в качестве бонуса)
Большинство коммерческих курсов - да. Но есть бесплатные курсы от компаний, в которых бывает полезно. Проходил такой от МТС пару лет назад, для меня это был легкий способ войти в Go, имея опыт в другом языке. Доступная информация, классные менторы. Практические задания для меня были мотивацией потратить время на изучение языка на практике. После курса получил 3 оффера из бигтехов РФ, в одном из которых работаю до сих пор.
@@user-cq7gb9gj4e Вам повезло) я не имею ввиду, что все вокруг шарлатаны.. всего лишь 99% населения планеты
зная как работает ужасно Авито, лучше всерьез не слушать данный доклад
Зная как устроен интернет, лучше всерьез не слушать комментарии😄
@@olezhek28go согласен, но очень прощу почините Авито уже, так плохо работает =((
Я во внутренних сервисах тружусь, так что над основным сайтом власти не имею(
А че не так с авито? Вроде нормально там ручки отвечают, никогда долго не ждал ответа