Архитектура Golang приложений 🚀Разбор реального проекта
HTML-код
- Опубликовано: 19 июн 2024
- Roadmap по каналу - bit.ly/3yKtxWf
Курс GOLANG NINJA - bit.ly/3VWKfu3
Обновленное видео 2022 - • Архитектура Golang При...
00:00 - Введение. Flat архитектура приложения на моем первом проекте с Golang
02:37 - Лучшие практики проектирования структуры приложений
04:22 - Директория /cmd
10:08 - Еще один пример структуры проектов. Пакеты pkg и internal
15:25 - Дополнительные директории в проекте. Пример API документации
20:05 - Детальный разбор internal. Чистая архитектура.
#golang #backend #архитектура
Обновленное видео 2022 - ruclips.net/video/mesl2Si6saw/видео.html
то есть это можно не смотреть?
мне кажется совсем другой человек 2021 - 2024
Спасибо тебе, мужик! Было капец как полезно! Я сейчас на стажировке и мне остро не хватало как раз таких разъяснений "по полочкам"
Спасибо большое за видео, очень рад что нашёл ваш канал) продолжайте в том же духе!
Путаете немного Инверсию зависимости(DIP) и Инъекцию зависимости(DI). Вообще названия не удачные поэтому путаница возникает между Инверсией зависимости, Инъекцией зависимости, Инверсией Управления. А так же Repository выродился в Gateway. Домен выродился в Анемичную Модель, то есть модель без поведения. Интерфейсы немножко пухловаты для инверсии, и лежат не на том слое, но шаги в правильном направлении, я уж так, придирки)) А вообще Вы молодец что просвещаете народ!
Согласен, сложно смотреть когда понимаешь паттерны и думаешь де блин)
@@hedinsss а какие именно тут паттерны?
@@Levelord92 еврейские
Спасибо друг! :) Стало все намного понятнее.
Супер, молодец, удачи тебе!
Ух, сколько связей и переплетений)
А я только на начале изучения языка Go, а здесь уже проект! интересно было просмотреть структуру, что-то думаю поймется со временем. Спасибо!
Отличное видео. Спасибо!
Спасибо! Весьма и весьма полезно.
Супер видео!!!
Давай еще)))
Спасибо, очень интересный материал! Максим, будем очень благодарны, если опубликуешь в гитхабе проект с подобной структурой. Очень хочется поиграться и изучить подробнее.
Классно объясняешь, спасибо)
Спасибо огромное! За моими плечами только один очень редкий фреймворк, для которого структуру мы разрабатывали сами. Так как я сейчас изучаю go, было очень интересно сравнить и сопоставить мои знания с новыми.
очень интересная структура! Большое спасибо!
Я снова влюбился в go и спасибо за инфу про организации приложения!
Отличный видос!
Это если не лучший, то один из лучших каналов по данной тематике на русскоязычном ютубе 🔥
Очень полезное видео, спасибо
Огромное спасибо за это видео, долго не мог понять из статей как грамотно орагнизовать структуру проекта. Было бы круто, если бы ты записал более подробное видео по чистой архитектуре и по чистому коду, в частонсти про SOLID в го. Есть масса статей, но они как правило очень поверхностно описывают эти принципы.
насколько я слышал в го нет классического ооп, но есть свои подобия
На юдеми курс golang-ninja от максима. И там есть глава чистая архитектура. Как раз перед этой главой шла часть с ссылкой на этот видосик
Благодарю за информацию!
Ахренеть, как круто и доступно объясняешь :) спасибо!
оооо) реализация ddd в go) интересно, интересно)
Крутой канал. Продолжай пожалуйста
как же ты по красоте делаешь
Личные ключи в головном readme - это, конечно, сильно! ;-)
Супер Макс. Хотелось бы потом по этому проекту, хотя бы в простой версии увидеть курс. Интересно как ты изначально настраиваешь проект, папки, структуры и тд. Также интересно было как ты настроил свой Goland, какая тема, какой шрифт
Golang у меня стандартный) Только немного хоткеи под себя настроил.
На канале скоро будет курс по телеграм боту с нуля, там все эти моменты будут разобраны)
Есть подход с генератором проектов. Можно написать утилиту, которая сразу создаёт нужные папки/файлы, прописывает везде всё нужное. Но это актуально если веб-приложения (микросервисы) однотипные по структуре и их много.
Большое спасибо за видео и за код, очень важно что такие люди как вы открывают код в опенсорс и показывают как "правильно" создавать проекты
как пинок в правильном направлении, зачёт.
Отличное видео. Спасибо. Создай видео как работать со Swagger. Так как ты умеешь. Четко, без воды и по существу )).
Уже записано, скоро будет на канале)
Видос классный, очень полезный для меня, подписался. Только, на мой взгляд, во второй половине ты слишком углубился в объяснение ддд. Возможно стоило рассказать с мыслью о том, что мы знаем что это, а для тех, кто не знает записать отдельное видео. Спасибо
Спасибо, рад что видео оказалось полезным.
Думаю не все кто посмотрит знает про ддд и чистую архитектуру, хотелось чтобы по просмотру не оставалось много вопросов)
актуальненько :3
офигеть насколько это сложно, но красиво..
Спасибо! Очень полезное видео. Когда только начинал погружаться в язык (думал сделать его основным перейдя с php), было не понятно как структурировать проект. Много информации было перелопачено. Я так же нарывался на этот репозиторий с бест практисами для структурирования приложения. Здесь же, при просмотре видео, все стало более чем понятно!
Очень рад что видео оказалось полезным!
О пожеланиях: было бы здорово на вашем канале посмотреть как на Го работать с брокерами сообщений (Кафка, Раббит)
Спасибо за идею, учту!
спасибо за видео, если возможно пожалуйсто увеичивайте шрифт в редакторе и по возможности названия папок со шрийтом побольше. в любомслучае спасибо
Все супер, единственное было бы хорошо если нижнюю часть экрана не обрезали. К примеру терминал был не полностью виден.
очень хороший контент! спасибо за проделанную работу!
Вопрос : какой опыт работы с Go и в целом программистом?
Спасибо за отзыв!
Программирую еще с детства, на первую работу веб-разработчиком устроился в 2016-ом, с Golang работаю с начала 2018-го
Хм хм, а если мы в cmd хотим запихнуть ещё один проект с main. То для этого нового проекта, где будут храниться пакеты? Видимо так же в internal и pkg. И получается некоторые пакеты используются совместно двумя проектами, некоторые пакеты уникальны для одного проекта. Так как же разрабу понять, какие куда относятся и можно ли что-то поменять для одного проекта и при этом не сломать другой?
Вот этого я не понял.
Спасибо что делитесь опытом. Имхо подход Feature by package самый топовый подход который подойдет для всех видов приложений
Сначала делим на бизнес логические сущности (модули)
user
profile
payment
cart
А дальше в каждой папке будет
user
->features
->login
-> repositories
-> services
-> forms
По гуглю по читаю, спасибо. Сам вот делаю первые шаги в go, до этого немного писал на python
Спасибо за ключи, генерировать заново не обязательно ;)
😂😂
Браво, хороший разбор, DI (e.g. Wire) не пробывал?
Вот в том же репозитории есть ссылки на видосы по архитектуре, советую глянуть.
Там подробно рассматриваются разные подходы. Начиная с плоской и заканчивая хексагональной с группировкой по функционалу
А можешь посоветовать какую-нибудь библиотеку для работы c Excel (XLSX) открытие/редактирование/запись, но чтобы она работала на старой версии 1.10
Не могу найти...
Очень классно объясняешь, спасибо)
Спасибо за отзыв! стараюсь)
Про репозитории интересно , пойду смотреть еще видео, реально примеров адекватных по работе с бд нет и разделение удачное по моделям / сервисам / репозиториям. Еще нет видоса хорошего по graphql
Коммент для активности
Красава!
Это нормально, что у нас service зависит от структуры Repositories и хэндлер от структуры Services? Там конечно содержатся интерфейсы как поля, но все же это не нарушение Clean Architecture? Это удобно конечно, но не лучше ли такие dependency injection проводить с мэина? например сохдать десять репозиториев и уже их запихнуть в сервис напрямую и то же самое с хэндлером? Тогда получится куча репозиториев и куча стуктур сервисов вместо одного, но не будет ли так правильнее?
Если у вас один main, имхо не нужно создавать cmd, т.к. смысл доп усложнения структуры папок в том, чтобы решить задачу разделения мейнов.
насколько я знаю, в GO принято объявлять интерфейсы в местах использования, а не рядом с имплементацией. Тут же всё наоборот (например, в папке репозитория).
абсолютно верно!
все верно, так уж пошло на этом проекте) новые стараюсь писать следуя этому принципу
(Совершенно искренний вопрос): А можно тему поподробнее раскрыть, с примером и объяснением "почему". И что делать, если интерфейс используется в нескольких местах?
@@vadimadamlyuk7487 Go отличается по работе с интерфейсами от других языков, где обычно есть что то типа implement, в таких случаях мы должны декларировать интерфейс до использования, в случаи с go, нам не нужно явно имплементировать интерфейс, мы можем работать со структурой а только потом назначить для нее интерфейс, это и есть основный смысл держать интерфейсы ближе к имплементации. А экспортить интерфейсы нам не кто не запрещает, и более того они для этого и нужны т.я именно на интерфейсах строится контракт между сервисами
Не раз слышал о том что не нужно мешать подходы из Java/C# к Go, и советуют не использовать DDD а использовать обычный go-way.
А причем тут DDD и язык? DDD это не про язык и не про программирование, это проектирование. Реализовать можно на любом языке язык это инструмент. DDD это про архитектуру6 фундаментальные принципы проектирования сложных систем, например такой фундаментальный шаблон как Единый Язык это не про программирование.
Спасибо огромное за видео, сам пишу также проекты (не только на GO) с применением Чистой Архитектуры. Хотел бы у тебя узнать, почему у тебя интерфейсы слоя Repository зависят от примитивов MongoDB типа primitive.ObjectID? Интерфейсы Repository должны быть более абстрактными и не привязываться к деталям реализации. В случае, если придется заменить источник данных, например, на Postgres возникнут проблемы. Думаю, лучше было бы заменить primitive.ObjectID на какой-нибудь string, а внутри уже конкретной реализации, в твоем случае MongoDB, преобразовать string в primitive.ObjectID.
Если спустя полгода-год работы над проектом прийдется заменить Mongo на Postgres, то ObjectID в интерфейсах будут самой незначительной проблемой)))
Спасибо за отзыв, рад что видео оказалось полезным
Спасибо, полезная информация. У меня есть пара вопросов:
1) У тебя в домене IDs в structs имеют тип primitive.ObjectID. Не нарушает ли это идею чистой архитектуры, что entities не должны знать какая база данных используется.
В случае если id передается как string параметром в route, то в каком слое ты приводишь string к objectID, в delivery ? И не лучше ли все эти конвертации проводить в репозиториях и ID на structs хранить как strings ?
2) Метод SignIn в StudentsService принимает StudentSignInInput struct объявленный, как я понимаю, в handler, то есть в StudentsService будет input из верхнего слоя. Это нормальная практика, или может такие structs лучше держать в domain или service ?
Спасибо, рад что видео оказалось полезным.
1) Да, нарушает. Однако я пришел к такому выводу, что проще все это хранить в таком виде, поскольку база данных MongoDB скорее всего никогда не поменяется. Если же вдруг и поменяется, намного больше головняка будет с миграцией данных с одной базы в другую и рефакторингом инфраструктуры, чем с изменением типа поля в структуре :)
2) StudentSignInInput объявлен в пакете service
@@MaksimZhashkevych тогда зачем объявлять интерфейс в репозитории?
@@cjo737 Чтобы можно было покрыть сервисы юнит тестами, а в качестве репозиториев использовать моки
@@MaksimZhashkevych В Go без интерфейса нельзя делать стабы/моки на основании сигнатур имплементации сервиса?
@@MaksimZhashkevych интересно конечно писать интерфейсы для тестов))
Скажите, а какова скорость написания кода относительно, допустим node.js или других технологий? Как часто стартапы в WEB берут Golang в качестве основного языка?
Два последних проекта на которых я работал - это были стартапы.
Скорость разработки много в чем зависит от команды, инструментов, автоматизации рутинных задач и выстроенных процессов. Если команда хорошо знает ноду, то конечно запустить проект на Go будет дорого и сложно, и наоборот)
Интересно) Можно пожалуйста увидеть инверсию зависимостей? Почему domain? просто у меня идут какие-то недопонимание. Почему изначальное не http2?
Domain - от подхода DDD(Domain Driven Design).
Вопрос про http не совсем корректный. Пакет v1 предназначен для инициализации группы эндпоинтов /api/v1
Спасибо за видео. Только если возможно, то хотелось бы крупнее шрифт в ide.
Спасибо, учту!
Фоновая музыка иногда сливается с речью и мешает восприятию, убавьте 🙏
Классная подача и подробный разбор тем, лайк!
Максим, сделай пожалуйста курс по Kafka
какой смысл в /internal/, если там код для приложения, но его нельзя использовать (он НЕ клонируется)?
Я искал подобную информацию во множестве видео, но во всех оказались какие-то онлайн-школы.
Что ж, тут по крайней мере не попытались впарить промокод да и сама школа всего лишь в коде.
Так что с моей точки зрения - одобрено
А как организованы Unit тесты в проект на Go?
Спасибо, хорошо описано. Я аналогично пишу.
Хотелось детальней взглянуть на репозиторий. Ссылочка есть?
Да, проект в открытом доступе на моем Github:
github.com/zhashkevych/courses-backend
@@MaksimZhashkevych thanks
@@MaksimZhashkevych скажи пожалуйста, как корректно назвать такую архитектуру. Т.е. ты в видео озвучил, что есть архитектура flat. А как корректно назвать архитектуру, которую ты используешь в видео?
@@vladimireliseev7602 clean architecture
Когда планируется релиз книги "Архитектура Современных Веб-Приложений" ?
Владимир, материал книги уже почти готов, однако в процессе работы я решил дополнить текст дополнительными видеоуроками. По итогу весь этот проект перерос в полноценный курс.
Сейчас я активно работаю над платформой, на которой будут опубликованы "Язык Go Для Начинающих" и "Архитектура Современных Веб-Приложений". Платформа позволит безболезненно обновлять и дополнять материалы курса, а также предоставит более удобный формат для его прохождения.
Подробную информацию я скоро сообщу в email-рассылке для всех, кто скачал первую главу.
С таким кодом это будет натуральная диверсия. Какие книги могут быть у пионеров? Вопрос риторический
💪👍
дякую
Все круто🔥, только(!), пожалуйста, называй папки - директориями, а файлы(.go) - пакетами🙏. Удачи в развитии канала🍀
Пакет это не файл, а папка
👍
Путь "internal->delivery" я бы переименовал в "internal->transport". Вы ведь так и называете его на русском. Потому как слово "delivery" имеет смысл "доставка", как доставка пиццы, в одну сторону - по направлению к объекту получателю.
хорошее замечание, имеет смысл, спасибо
я однажды столкнулся с delivery на одном проекте - так и приелось)
У вас на гитхаб, в том проекте который вы позиционируете как клин архитектур, нет папки internal, это нищетово, мне хотелось посмотреть как вы с ним работаете.
можно ли в main подключить локальные пакеты без указания пути через github?
Да. Пример: "pkg/auth", если ссылки на хаб нету, он в корне проекта ищет директорию pkg и в ней пакет auth. Поиск не относительно исполняемого файла, а от корневого каталога - это важно.
Посмотрел курс по RestAPI и вернулся сюда, todo буду переносить на эту структуру, заодно и отточу понимание что и как программировать на go.
Я загорелся желанием уйти от php и забыть его как страшный сон )
Чего страшного в пхп?
@@xbsxbs22 страшного ничего нет, а вот атавизмы из-за его возраста присутствуют.
@@kyleRQWS Какие к примеру?
@@xbsxbs22 Функции str_* и с иным форматом наименования strstr strpos, file_exists и filesize.
@@kyleRQWS Не совсем понимаю, в чём проблема с именами этих обёрток? они вполне себе заимствованы из библиотек С. Разве Go отличается каким-то особенно отточенным и выверенным неймингом?
интерфейс и подсветку vs в goland и было бы зашибись)
А ссылки нет. И, на хабе, также найти не найти данный пример(
Так как по Go это сейчас самый адекватный ресурс на русском. Разрешите спросить
package main
import "fmt"
func main() {
p0 := new(int)
x := *p0
p1, p2 := &x, &x
fmt.Println(p1 == p2) // true
fmt.Println(p0 == p1) // false
p3 := &*p0
fmt.Println(p0 == p3) // true
}
не могу вкурить, что произошло вот в этой строке p3 := &*p0
Ну какой крон уж?) Тайм тикер есть... А вообще, очень полезное видео!)
Мне кажется для веб сервера не походит internal, т.к. такие приложения вряд ли будут импортировать, поэтому защищать от импорта не нужно.
Мне кажется логичнее pkg не использовать в таком случае 😀 а то странно держать бизнес логику в «публичных» пакетах
При регистрации на твоём сайте получил письмо с битой ссылкой ( текст выделяется, самой ссылки для активации нет )
:)
Проверил, все работает, а подскажи свой email?
@@MaksimZhashkevych botanprog@aol.com
@@MaksimZhashkevych Пользователь с таким email уже зарегистрирован. Если возникли проблемы, напиши мне на zhashkevychmaksim@gmail.com
Решил погрузится в го (по работе хотелось бы переписать один небольшой специфичный микросервис с ноды)
обычно я стараюсь следовать стайлгайдам конкретных технологий, но, блин, почему в Го так любят все сокращать, переменные из двух букв, обрубленные слова, котрые часто вижу в исходниках библиотек (например, pkg - вместо package, sk - вместо signingKey, sd - вместо seed, h - вместо handler) и тд
Это реально так приянто в Го или мне просто такой код попадается странный
Дичь же полная, программы люди же читают, зачем символы экономить, жертвуя читабельностью?)
Есть такое. В стандартной либе тоже такая фигня. Напр. в функции могут встретиться переменные n, s, t и nn, и хер разбери, что они значат. Сам я нарушаю эти правила и пишу без сокращений.
Потому что Амеры любят сокращать, и зык сам не Golang a Go....
я бы использовал DTO.
Что за IDE?
Goland
Чё 2160p это каК?
Я кстати успел поюзать ключи если что
без проблем, проект неактивный уже давно, юзай наздоровье
а где тесты если это реальный проект? только один увидел, где остальные?
Макс, расскажи как тебя взяли голанг-джуном когда ты толком не знал языка?
Я показал работодателю что я проактивный, могу быстро учить новое, имею дикое желание развиваться как специалист.
Также было плюсом что я до этого уже работал в 16 веб-разработчиком, а также у меня был профиль на фрилансе с 6 положительными отзывами.
Ну и я выполнил 2 тестовых задания на Go, которые мне скинули)
@@MaksimZhashkevych А щас вы также работаете Go Backend разработчиком?) Спасибо за ваши видео, они помогают, надеюсь их будет больше и они будут полными , то есть front + back + docker + db и т д)
Очередной недо-DDD/clean architecture. Переименуй entity в model и не путай людей. У тебя там сейчас описаны типичные модели ничего не имеющие общего с entity. Возможно, что-то поменяется когда начнёшь писать тесты, но пока это Франкенштейн какой-то. Например, как минимум entity вообще ничего про JSON и как они представлены во внешних слоях знать не должны. И методов там кроме доменной (бизнес) логики никаких не должно быть.
У меня другая структура а тут даже папки вендора нет)
Писал отзыв развернутый и текст изчез. Коротко, инверсия зависимостей и внедрение зависимостей это разные вещи. У вас в проекте нет инверсии зависимоетей, и буква D в SOLID не соблюдается.
4-ый раз смотрю это видео полностью уже, каждый раз с пользой. Слава Украине!
"имеет место", а не "имеет место быть". Второе -- это ошибка.
Эх, хорошие раньше видосы были, сейчас, к сожалению, сплошное водогонство пошло.
эх, как жаль..
Никогда такими шаблонами не пользуйся. То что тут промахивается в видосе, это полная жесть
Чем огорчают нынешние детки, сразу оговорюсь, что не все - мы уже все знаем и все умеем. 10К часов или 10 лет никто не отменял, вместо того, чтобы пачкать мозги другим нужно ботанить это время
Мляя, без музона слабо????
словно евровидение освещаете...
Очередной пухлый роман вместо микросервиса
Нет ни одной причины повторять информацию в видео несколько раз. Понятнее от этого не становится, только раздражает. Видео можно перематывать, если захочется послушать еще раз.
Не понял.. в чем прикол? этот проект можно куда проще реализовать на любой адекватной срм symphony, laravel, typo3.. да хоть самому с 0 написать.. Зачем использовать для этого GO? Создать новый язык что бы что? писать сайты??))
Курс GOLANG NINJA - bit.ly/3VWKfu3
Какая цена примерно будет? Или пока что не думал?