С радостью хочу вам представить, что я запускаю курс “Начальная подготовка” по языку Golang. Курс как для совсем начинающих в сфере IT, так и для тех, кто хочет просто изучить язык Go. Курс доступен в 3 вариациях: 1. Онлайн курс с лекциями, заданиями, чатом менторской поддержкой. 2. Полный видеокурс 3. Отдельные блоки с лекциями Больше обо мне и курсах можно прочитать здесь: bit.ly/3XK1oZp Записаться на курс можно вот тут: bit.ly/406V3IY А видео курс тут: bit.ly/406VgMg А отдельные блоки с видео тут: bit.ly/3Rfmhcj Больше информации есть в ролике на ютубе: th-cam.com/video/E0b0dmwf-6c/w-d-xo.html На все вопросы могу ответить в Телеграм группе канала и в личных сообщениях.
Дружище, ты очень крут в донесении информации и её подаче. Благодарю за труды. Твои видео очень полезны, пусть у тебя всегда будет вдохновение помогать людям )
Лучший канал о Go!!!! Понять возможно только если сталкивался с реализацией архитектуры. Но если сталкивался, то польза этого видео зашкаливает!!!! Доначу просто из благодарности за моё съэкономленное время и нервы!!!
Большое спасибо, отличное видео! После просмотра Go Advances как раз было неполное понимание что куда и для чего, а здесь все супер понятно объясняется!
По сути, все что сделано, это структура папок. Идеи на будущее: 1) Где будет жить валидация запросов к API (не только формата и набора полей, но и допустимых значений с учетом уровней доступа) 2) Где будет жить в целом разграничение доступа и роли (GetAllBooks может быть разным для разных ролей) 3) Связи доменных сущностей, контексты и реализация их мапинга в репах, без этого вообще нет смысла рассматривать чистую архитектуру
@@bestia96 ее нету, когда понимаешь и принимаешь это, то идешь учить алгоритмы, распределенные системы или еще что реально полезное, а не жевать козявки
спасибо большое за видео. обычно storage(репозиторий) кладу рядом с сервисом(в той же директории). так получается целый контекст упакован в одном пекадже. этакий микросервис внутри приложения. а так со всем согласен, все здорово. продолжение ждем)
Спасибо! Понятно и понравилось, жду продолжение! Но есть два замечания: 1) На 35:38 минуте вы сначала отправляете тело запроса, а затем заголовок. надо наоборот. 2) На 24:51 минуте зачем возвращать указатель на Book? Так память будет выделена в куче, что создаст лишнюю нагрузку на сборщик мусора. Лучше отдавать копию Book, так память будет выделена в стеке.
В случае с возвратом указателя можно вернуть nil, а куча для того и нужна, чтобы память для объектов выделять. Выделять память на стеке под большие бизнес-объекты совершенно ни к чему.
Споткнулся на первой же модели. Знание, что книжка занята и кем занята некорректно размещать в модели Book. Мы зачем-то осознанно ограничиваем варианты использования этой модели одинм сценарием. Смотрю дальше.
1. почему интерфейсы определены на стороне продьюсера ? 2. Почему функция возвращает интерфейс вместо того, чтобы возвращать конкретный тип ? По конвенции, функция получает интерфейс, а возращает конкретный тип же - конечно, это правило, а правило не всегд придерживается ) 3. Почему функция усложняется тем еще, что возращает пойнтер к структуру ? Ведь пойнтеры не всегда полезны для рантайма для маленьких данных.
все круто и понятно) может попробовать прям как по книжке с пресенторами, юзкейсами интеракторами для них? Еще как вариант, можно кроме рест интерфейса показать пример с cli интерфейсом, когда условно говоря у тебя нет риквеста
Не стоит переносить подходы Java в Go один к одному да и не получится. Принципы нужно перенимать. Гексагональная, Луковая или Чистая - суть одна, адаптеры и инверсия зависимости - и все по сути. Чистая архитектура конечно очень полезна убрать инфраструктуру и привести все в порядок, но она автоматически не спасет от спагетти кода в самом домене. Если хотите прямо разобраться и все увязать вместе то есть серия публикаций Герберто Граца, там все сведено в одну большую схему с подробностями и объяснениями и гит есть правда насколько помню на ПХП
imo излишне было разделение на субдоменные директории в domain, и директория adapters. и еще вопрос про клиент в pkg: разве его не надо инкапсить в internal? его ведь юзать будет только наша прилога. я как понял, переходя на го, что в pkg интерфейс нашей прилоги для го модулей
@@TheArtofDevelopment возможно я не так понял концепт разделения на pkg и internal, поправь, если не прав: internal инкапсулирует всю логику приложения и запрещает её импорт извне. Pkg же является интерфейсом приложения для взаимодействия (например для go module) и юзает все, что в интернал, так?
Какой-то квантовый скачок прям от видео описания языка к видео написания приложений на данном языке. У меня постоянно возникали вопросы зачем и почему? Зачем нужна "чистая архитектура"? Зачем такая структура директорий? Термины проектирования, которые плохо согласуются с терминами бизнес-логики (домен, сервис в нескольких местах, модель, адаптер, порт, регистр, контроллер, интерфейс и т.д. и т.п.). И ведь эти абстракции явно ничего общего не имеют типами самого языка и плохо согласуются с терминами из смежных областей (сети, базы данных, кубренетес, что угодно). Плохо акцентирован момент передачи точки управления между слоями (я программист не настоящий, но всё через интерфейсы го, вместо передачи ссылки на структуру, видимо с этим связано). Короче. Если вы, например, из смежной it-области, то тут вы и приплыли. Нужны уроки на тему как писать приложения, почему именно так и к чему приводит если вот не так, а иначе. Миллион проектов работающих на гитхабе которые вот прям совсем не так. Пожелания по новым урокам. 1) Дебаггинг в go. 2) go для девопсов (+ взаимодействие с api kubernetes) best practice построения пайплайна для го приложения. (когда и как запускать лучше тесты, линтёры-форматеры, сонаркуб, паковка в образ, миграция бд ликвибейзом или чем на го меняется бд и т.п.) Если есть такой опыт, кончено. 3) Цикл: "изучаем чужой код(т)". Что хорошо, что плохо и почему? 4) Как написать свой модуль и выложить в опенсорс? Как правильно документировать ? 5) Обвес современного приложения (микросервиса) на go (трассировка jagger, метрики прометеуса, правильное логирование в том числе паник и укладывания их в json -- чтоб красиво в кибане и т.п.). Параметризация приложения без рестарта. Swagger. И... уроки в целом хороши. Наверное пока лучшее на русском по go.
Короче, для потомков, кто будет смотреть в 2023 и позже. Не тратьте время. В итоге он ничего не доделал, во второй части правит первую, в третьей вторую, в репо вообще другая структра папок в итоге и ничего не закончено и там. Опытным разрабам - бесполезно, новичкам - вредно. Шлак.
С радостью хочу вам представить, что я запускаю курс “Начальная подготовка” по языку Golang. Курс как для совсем начинающих в сфере IT, так и для тех, кто хочет просто изучить язык Go.
Курс доступен в 3 вариациях:
1. Онлайн курс с лекциями, заданиями, чатом менторской поддержкой.
2. Полный видеокурс
3. Отдельные блоки с лекциями
Больше обо мне и курсах можно прочитать здесь:
bit.ly/3XK1oZp
Записаться на курс можно вот тут:
bit.ly/406V3IY
А видео курс тут:
bit.ly/406VgMg
А отдельные блоки с видео тут:
bit.ly/3Rfmhcj
Больше информации есть в ролике на ютубе:
th-cam.com/video/E0b0dmwf-6c/w-d-xo.html
На все вопросы могу ответить в Телеграм группе канала и в личных сообщениях.
Сказочный голос героя слушал как сказку на ночь )) Спасибо
Дружище, ты очень крут в донесении информации и её подаче. Благодарю за труды. Твои видео очень полезны, пусть у тебя всегда будет вдохновение помогать людям )
Спасибо за тёплые слова!
Лучший канал о Go!!!! Понять возможно только если сталкивался с реализацией архитектуры. Но если сталкивался, то польза этого видео зашкаливает!!!! Доначу просто из благодарности за моё съэкономленное время и нервы!!!
Лучшее видео по теме на русском! Спасибо!!!! Наконец-то стало понятнее
представляю насколько все это сложно делать и записывать, но я тебе очень благодарен за твой труд. спасибо
Большое спасибо, отличное видео! После просмотра Go Advances как раз было неполное понимание что куда и для чего, а здесь все супер понятно объясняется!
доходчиво и понятно объясняете и рассказываете. с примером в коде гораздо легче усваивается.
спасибо!
По сути, все что сделано, это структура папок. Идеи на будущее:
1) Где будет жить валидация запросов к API (не только формата и набора полей, но и допустимых значений с учетом уровней доступа)
2) Где будет жить в целом разграничение доступа и роли (GetAllBooks может быть разным для разных ролей)
3) Связи доменных сущностей, контексты и реализация их мапинга в репах, без этого вообще нет смысла рассматривать чистую архитектуру
Записал
Можете подсказать, есть где-либо пример самой "правильной" реализации микросервиса с учетом всего возможного
@@bestia96 ее нету, когда понимаешь и принимаешь это, то идешь учить алгоритмы, распределенные системы или еще что реально полезное, а не жевать козявки
спасибо большое за видео.
обычно storage(репозиторий) кладу рядом с сервисом(в той же директории). так получается целый контекст упакован в одном пекадже. этакий микросервис внутри приложения.
а так со всем согласен, все здорово. продолжение ждем)
Отличное видео, очень жду продолжения. Спасибо за твои труды
спасибо за фидбек!
Да, всё по фэн-шую, но перегруз случился хаха. Хотим часть 2
Однозначно нужно продолжение. Ждем!
спасибо за фидбек! будет!
C чуством юмора у тебя все в порядке, ставлю лайк
Круто объясняешь, давай больше про архитектуры и различные подходы
Да отлично вообще, конечно, надо продолжать!)
спасибо за фидбек!
Спасибо! Все понятно! Ждем продолжения!
Спасибо за видео! В целом понятно, но чувствую придется пересматривать. Пойду смотреть следующие части.
Спасибо! Понятно и понравилось, жду продолжение!
Но есть два замечания:
1) На 35:38 минуте вы сначала отправляете тело запроса, а затем заголовок. надо наоборот.
2) На 24:51 минуте зачем возвращать указатель на Book? Так память будет выделена в куче, что создаст лишнюю нагрузку на сборщик мусора. Лучше отдавать копию Book, так память будет выделена в стеке.
пересмотрю - отвечу
В случае с возвратом указателя можно вернуть nil, а куча для того и нужна, чтобы память для объектов выделять. Выделять память на стеке под большие бизнес-объекты совершенно ни к чему.
Супер! Ждём продолжения!
понял, принял
Спасибо! Отличные видео делаете!
спасибо за фидбек!
Споткнулся на первой же модели. Знание, что книжка занята и кем занята некорректно размещать в модели Book. Мы зачем-то осознанно ограничиваем варианты использования этой модели одинм сценарием.
Смотрю дальше.
Поддержу лайкосом, жаль что на полуслове.
А это чтобы понять нужна ли вторая часть :)
Огонь, очень круто, спасибо большое
Шикарно
Спасибо!
красавчик.!
риспект
молоцо
благодарю!
Огонь, спасибо за урок)
Кайф, спасибо!
хороший материал , лайк, подписка)
спасибо за фидбек!
Ты лучший! Спасибо большое!
Мощь!!!
Спасибо. Значит вторую часть делать? )
@@TheArtofDevelopment обязательно!!!
Сейчас мало просмотров, но думаю со временем люди найдут ваш канал будут также как и я кайфовать)))
@@TheArtofDevelopment Обязательно!!!
1. почему интерфейсы определены на стороне продьюсера ?
2. Почему функция возвращает интерфейс вместо того, чтобы возвращать конкретный тип ? По конвенции, функция получает интерфейс, а возращает конкретный тип же - конечно, это правило, а правило не всегд придерживается )
3. Почему функция усложняется тем еще, что возращает пойнтер к структуру ? Ведь пойнтеры не всегда полезны для рантайма для маленьких данных.
Коллеги, подскажите, пожалуйста, почему мы передаем service в NewHandler в controllers не по ссылке?
а зачем нужна ссылка?
все круто и понятно) может попробовать прям как по книжке с пресенторами, юзкейсами интеракторами для них? Еще как вариант, можно кроме рест интерфейса показать пример с cli интерфейсом, когда условно говоря у тебя нет риквеста
можно. но зачем? архитектура должна же помогать, а не мешать :-)
а вот про CLI интересно - надо будет подумать
Не стоит переносить подходы Java в Go один к одному да и не получится. Принципы нужно перенимать. Гексагональная, Луковая или Чистая - суть одна, адаптеры и инверсия зависимости - и все по сути. Чистая архитектура конечно очень полезна убрать инфраструктуру и привести все в порядок, но она автоматически не спасет от спагетти кода в самом домене. Если хотите прямо разобраться и все увязать вместе то есть серия публикаций Герберто Граца, там все сведено в одну большую схему с подробностями и объяснениями и гит есть правда насколько помню на ПХП
@@aidarlatypov7747 надо глянуть, спасибо
@@aidarlatypov7747 буду оч признателен, если поделитесь ссылочкой на гит
@@jonik_doit4463 Напишите свой телеграмм, это еще найти же надо.. ) Прямо сейчас не могу
imo излишне было разделение на субдоменные директории в domain, и директория adapters.
и еще вопрос про клиент в pkg: разве его не надо инкапсить в internal? его ведь юзать будет только наша прилога.
я как понял, переходя на го, что в pkg интерфейс нашей прилоги для го модулей
про субдоменные директории в domain возможно соглашусь, а вот про pkg не понял
@@TheArtofDevelopment возможно я не так понял концепт разделения на pkg и internal, поправь, если не прав: internal инкапсулирует всю логику приложения и запрещает её импорт извне.
Pkg же является интерфейсом приложения для взаимодействия (например для go module) и юзает все, что в интернал, так?
Топ контент
Спасибо, лайк. Зачем контроллеры пихать в папку адаптеры? Они же таковыми не являются?
являются. они адаптеры между транспортом и логикой
Спасибо
молодец
Можешь скинуть архив с итоговым кодом или залить на гит?
Как в эту архитектуру интегрировать Proto? Мы можем исключить в таком случае DTO или он всё ещё нужен?
@@kodaf DTO нужен. Интегрировать Proto можно
git будет
продолженние бы..
будет!
если Gateways это репозитори, то внешний слой DB это же репозитори ?
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к звездочек, мне понравился
я интерфейсы кидаю папку Port
Короче, для потомков, кто будет смотреть в 2023 и позже. Не тратьте время. В итоге он ничего не доделал, во второй части правит первую, в третьей вторую, в репо вообще другая структра папок в итоге и ничего не закончено и там. Опытным разрабам - бесполезно, новичкам - вредно. Шлак.
И что тогда смотреть? (И есть ли, или только читать)
Hexogonal .... и шести, а не пятиугольник... пяти - это пентагон..
Gateways это скорее API
нет, это вообще про другое
😂😂😂😂🤣🤣🤣
Классное видео. Спасибо за труды