Уроки по Golang. Advanced. Чистая Архитектура / Clean Architecture Часть 1
HTML-код
- Опубликовано: 6 сен 2024
- Пришло время пообщаться про чистую архитектуру и ее реализацию в Go.
Приятного просмотра!
GitHub репозиторий:
github.com/the...
С радостью хочу вам представить, что я запускаю курс “Начальная подготовка” по языку Golang. Курс как для совсем начинающих в сфере IT, так и для тех, кто хочет просто изучить язык Go.
Больше обо мне и курсах можно прочитать здесь:
artofedu.org/
Больше информации есть в ролике на ютубе:
• Анонс: Курс Начальная ...
На все вопросы могу ответить в Телеграм группе канала и в личных сообщениях.
Другие видео:
Уроки по Golang. Advanced. REST API. Вебсервер.
• Уроки по Golang. Advan...
Изучаем Python. Урок 1. Основы. Бонус: Пишем приложение на FastAPI • Изучаем Python. Урок 1...
Изучаем Golang. Урок 1. Основы + веб-сервер в 3 строки в конце урока! • Изучаем Golang. Урок 1...
Разработка системы заметок на Python, Golang и микросервисы в 2021 году • Разработка системы зам...
Как стать разработчиком. Часть 1 • Как стать разработчико...
Что такое микросервисы за 200 секунд • Что такое микросервисы...
Что такое Apache Kafka за 200 секунд • Что такое Apache Kafka...
Telegram Group: t.me/theartofd...
VK: thearto...
Дружественный Golang чат: t.me/gogolang
----
Меня зовут Артур Карапетов и я занимаюсь всем, что связано с разработкой. Я создаю высоконагруженные информационные системы, стартапы, занимаюсь личным обучением людей в сфере разработки (программисты, аналитики, системные администраторы), также я помогаю компаниям и стартапам с обучением людей работать и повышением их квалификации, об этом можно почитать здесь: mitkadr.ru.
На этом канале я выкладываю ролики на интересующие меня темы, здесь можно найти серию роликов про создание информационной системы с нуля, а также можно найти серию уроков по языкам, которые я люблю. Добро пожаловать и хорошего просмотра!
#golang #урок #restapi #rest #микросервисы #microservices #jetbrains #goland #tutorial #голенг #development #howto #learnbasics #coding #programming #изучаемIT #программирование #разработка
С радостью хочу вам представить, что я запускаю курс “Начальная подготовка” по языку Golang. Курс как для совсем начинающих в сфере IT, так и для тех, кто хочет просто изучить язык Go.
Курс доступен в 3 вариациях:
1. Онлайн курс с лекциями, заданиями, чатом менторской поддержкой.
2. Полный видеокурс
3. Отдельные блоки с лекциями
Больше обо мне и курсах можно прочитать здесь:
bit.ly/3XK1oZp
Записаться на курс можно вот тут:
bit.ly/406V3IY
А видео курс тут:
bit.ly/406VgMg
А отдельные блоки с видео тут:
bit.ly/3Rfmhcj
Больше информации есть в ролике на ютубе:
ruclips.net/video/E0b0dmwf-6c/видео.html
На все вопросы могу ответить в Телеграм группе канала и в личных сообщениях.
Дружище, ты очень крут в донесении информации и её подаче. Благодарю за труды. Твои видео очень полезны, пусть у тебя всегда будет вдохновение помогать людям )
Спасибо за тёплые слова!
Лучшее видео по теме на русском! Спасибо!!!! Наконец-то стало понятнее
Сказочный голос героя слушал как сказку на ночь )) Спасибо
Лучший канал о Go!!!! Понять возможно только если сталкивался с реализацией архитектуры. Но если сталкивался, то польза этого видео зашкаливает!!!! Доначу просто из благодарности за моё съэкономленное время и нервы!!!
Отличное видео, очень жду продолжения. Спасибо за твои труды
спасибо за фидбек!
Большое спасибо, отличное видео! После просмотра Go Advances как раз было неполное понимание что куда и для чего, а здесь все супер понятно объясняется!
представляю насколько все это сложно делать и записывать, но я тебе очень благодарен за твой труд. спасибо
По сути, все что сделано, это структура папок. Идеи на будущее:
1) Где будет жить валидация запросов к API (не только формата и набора полей, но и допустимых значений с учетом уровней доступа)
2) Где будет жить в целом разграничение доступа и роли (GetAllBooks может быть разным для разных ролей)
3) Связи доменных сущностей, контексты и реализация их мапинга в репах, без этого вообще нет смысла рассматривать чистую архитектуру
Записал
Можете подсказать, есть где-либо пример самой "правильной" реализации микросервиса с учетом всего возможного
@@bestia96 ее нету, когда понимаешь и принимаешь это, то идешь учить алгоритмы, распределенные системы или еще что реально полезное, а не жевать козявки
Однозначно нужно продолжение. Ждем!
спасибо за фидбек! будет!
доходчиво и понятно объясняете и рассказываете. с примером в коде гораздо легче усваивается.
спасибо!
C чуством юмора у тебя все в порядке, ставлю лайк
Круто объясняешь, давай больше про архитектуры и различные подходы
Да отлично вообще, конечно, надо продолжать!)
спасибо за фидбек!
спасибо большое за видео.
обычно storage(репозиторий) кладу рядом с сервисом(в той же директории). так получается целый контекст упакован в одном пекадже. этакий микросервис внутри приложения.
а так со всем согласен, все здорово. продолжение ждем)
Спасибо за видео! В целом понятно, но чувствую придется пересматривать. Пойду смотреть следующие части.
Супер! Ждём продолжения!
понял, принял
Спасибо! Все понятно! Ждем продолжения!
Да, всё по фэн-шую, но перегруз случился хаха. Хотим часть 2
Споткнулся на первой же модели. Знание, что книжка занята и кем занята некорректно размещать в модели Book. Мы зачем-то осознанно ограничиваем варианты использования этой модели одинм сценарием.
Смотрю дальше.
Спасибо! Отличные видео делаете!
спасибо за фидбек!
Шикарно
Спасибо!
Огонь, очень круто, спасибо большое
Спасибо! Понятно и понравилось, жду продолжение!
Но есть два замечания:
1) На 35:38 минуте вы сначала отправляете тело запроса, а затем заголовок. надо наоборот.
2) На 24:51 минуте зачем возвращать указатель на Book? Так память будет выделена в куче, что создаст лишнюю нагрузку на сборщик мусора. Лучше отдавать копию Book, так память будет выделена в стеке.
пересмотрю - отвечу
В случае с возвратом указателя можно вернуть nil, а куча для того и нужна, чтобы память для объектов выделять. Выделять память на стеке под большие бизнес-объекты совершенно ни к чему.
хороший материал , лайк, подписка)
спасибо за фидбек!
Огонь, спасибо за урок)
Поддержу лайкосом, жаль что на полуслове.
А это чтобы понять нужна ли вторая часть :)
Кайф, спасибо!
Мощь!!!
Спасибо. Значит вторую часть делать? )
@@TheArtofDevelopment обязательно!!!
Сейчас мало просмотров, но думаю со временем люди найдут ваш канал будут также как и я кайфовать)))
@@TheArtofDevelopment Обязательно!!!
Ты лучший! Спасибо большое!
красавчик.!
риспект
молоцо
благодарю!
1. почему интерфейсы определены на стороне продьюсера ?
2. Почему функция возвращает интерфейс вместо того, чтобы возвращать конкретный тип ? По конвенции, функция получает интерфейс, а возращает конкретный тип же - конечно, это правило, а правило не всегд придерживается )
3. Почему функция усложняется тем еще, что возращает пойнтер к структуру ? Ведь пойнтеры не всегда полезны для рантайма для маленьких данных.
все круто и понятно) может попробовать прям как по книжке с пресенторами, юзкейсами интеракторами для них? Еще как вариант, можно кроме рест интерфейса показать пример с cli интерфейсом, когда условно говоря у тебя нет риквеста
можно. но зачем? архитектура должна же помогать, а не мешать :-)
а вот про CLI интересно - надо будет подумать
Не стоит переносить подходы Java в Go один к одному да и не получится. Принципы нужно перенимать. Гексагональная, Луковая или Чистая - суть одна, адаптеры и инверсия зависимости - и все по сути. Чистая архитектура конечно очень полезна убрать инфраструктуру и привести все в порядок, но она автоматически не спасет от спагетти кода в самом домене. Если хотите прямо разобраться и все увязать вместе то есть серия публикаций Герберто Граца, там все сведено в одну большую схему с подробностями и объяснениями и гит есть правда насколько помню на ПХП
@@aidarlatypov7747 надо глянуть, спасибо
@@aidarlatypov7747 буду оч признателен, если поделитесь ссылочкой на гит
@@jonik_doit4463 Напишите свой телеграмм, это еще найти же надо.. ) Прямо сейчас не могу
Коллеги, подскажите, пожалуйста, почему мы передаем service в NewHandler в controllers не по ссылке?
а зачем нужна ссылка?
imo излишне было разделение на субдоменные директории в domain, и директория adapters.
и еще вопрос про клиент в pkg: разве его не надо инкапсить в internal? его ведь юзать будет только наша прилога.
я как понял, переходя на го, что в pkg интерфейс нашей прилоги для го модулей
про субдоменные директории в domain возможно соглашусь, а вот про pkg не понял
@@TheArtofDevelopment возможно я не так понял концепт разделения на pkg и internal, поправь, если не прав: internal инкапсулирует всю логику приложения и запрещает её импорт извне.
Pkg же является интерфейсом приложения для взаимодействия (например для go module) и юзает все, что в интернал, так?
я интерфейсы кидаю папку Port
Спасибо, лайк. Зачем контроллеры пихать в папку адаптеры? Они же таковыми не являются?
являются. они адаптеры между транспортом и логикой
Топ контент
Спасибо
продолженние бы..
будет!
если Gateways это репозитори, то внешний слой DB это же репозитори ?
Можешь скинуть архив с итоговым кодом или залить на гит?
Как в эту архитектуру интегрировать Proto? Мы можем исключить в таком случае DTO или он всё ещё нужен?
@@kodaf DTO нужен. Интегрировать Proto можно
git будет
молодец
UID надо передавать Удобно потом теснить без базы данных
Какой-то квантовый скачок прям от видео описания языка к видео написания приложений на данном языке.
У меня постоянно возникали вопросы зачем и почему? Зачем нужна "чистая архитектура"? Зачем такая структура директорий? Термины проектирования, которые плохо согласуются с терминами бизнес-логики (домен, сервис в нескольких местах, модель, адаптер, порт, регистр, контроллер, интерфейс и т.д. и т.п.). И ведь эти абстракции явно ничего общего не имеют типами самого языка и плохо согласуются с терминами из смежных областей (сети, базы данных, кубренетес, что угодно). Плохо акцентирован момент передачи точки управления между слоями (я программист не настоящий, но всё через интерфейсы го, вместо передачи ссылки на структуру, видимо с этим связано).
Короче. Если вы, например, из смежной it-области, то тут вы и приплыли. Нужны уроки на тему как писать приложения, почему именно так и к чему приводит если вот не так, а иначе. Миллион проектов работающих на гитхабе которые вот прям совсем не так.
Пожелания по новым урокам.
1) Дебаггинг в go.
2) go для девопсов (+ взаимодействие с api kubernetes) best practice построения пайплайна для го приложения. (когда и как запускать лучше тесты, линтёры-форматеры, сонаркуб, паковка в образ, миграция бд ликвибейзом или чем на го меняется бд и т.п.) Если есть такой опыт, кончено.
3) Цикл: "изучаем чужой код(т)". Что хорошо, что плохо и почему?
4) Как написать свой модуль и выложить в опенсорс? Как правильно документировать ?
5) Обвес современного приложения (микросервиса) на go (трассировка jagger, метрики прометеуса, правильное логирование в том числе паник и укладывания их в json -- чтоб красиво в кибане и т.п.). Параметризация приложения без рестарта. Swagger.
И... уроки в целом хороши. Наверное пока лучшее на русском по go.
а в go есть Command Bus?
сахар над комманд можно написать любой, а команда есть, да, но без наследования
ThreeDotsLabs/wild-workouts-go-ddd-example 3к звездочек, мне понравился
Hexogonal .... и шести, а не пятиугольник... пяти - это пентагон..
Короче, для потомков, кто будет смотреть в 2023 и позже. Не тратьте время. В итоге он ничего не доделал, во второй части правит первую, в третьей вторую, в репо вообще другая структра папок в итоге и ничего не закончено и там. Опытным разрабам - бесполезно, новичкам - вредно. Шлак.
И что тогда смотреть? (И есть ли, или только читать)
Gateways это скорее API
нет, это вообще про другое
😂😂😂😂🤣🤣🤣
Классное видео. Спасибо за труды