Путаете немного Инверсию зависимости(DIP) и Инъекцию зависимости(DI). Вообще названия не удачные поэтому путаница возникает между Инверсией зависимости, Инъекцией зависимости, Инверсией Управления. А так же Repository выродился в Gateway. Домен выродился в Анемичную Модель, то есть модель без поведения. Интерфейсы немножко пухловаты для инверсии, и лежат не на том слое, но шаги в правильном направлении, я уж так, придирки)) А вообще Вы молодец что просвещаете народ!
Огромное спасибо за это видео, долго не мог понять из статей как грамотно орагнизовать структуру проекта. Было бы круто, если бы ты записал более подробное видео по чистой архитектуре и по чистому коду, в частонсти про SOLID в го. Есть масса статей, но они как правило очень поверхностно описывают эти принципы.
Спасибо огромное! За моими плечами только один очень редкий фреймворк, для которого структуру мы разрабатывали сами. Так как я сейчас изучаю go, было очень интересно сравнить и сопоставить мои знания с новыми.
Ух, сколько связей и переплетений) А я только на начале изучения языка Go, а здесь уже проект! интересно было просмотреть структуру, что-то думаю поймется со временем. Спасибо!
Спасибо что делитесь опытом. Имхо подход Feature by package самый топовый подход который подойдет для всех видов приложений Сначала делим на бизнес логические сущности (модули) user profile payment cart А дальше в каждой папке будет user ->features ->login -> repositories -> services -> forms
насколько я знаю, в GO принято объявлять интерфейсы в местах использования, а не рядом с имплементацией. Тут же всё наоборот (например, в папке репозитория).
(Совершенно искренний вопрос): А можно тему поподробнее раскрыть, с примером и объяснением "почему". И что делать, если интерфейс используется в нескольких местах?
@@vadimadamlyuk7487 Go отличается по работе с интерфейсами от других языков, где обычно есть что то типа implement, в таких случаях мы должны декларировать интерфейс до использования, в случаи с go, нам не нужно явно имплементировать интерфейс, мы можем работать со структурой а только потом назначить для нее интерфейс, это и есть основный смысл держать интерфейсы ближе к имплементации. А экспортить интерфейсы нам не кто не запрещает, и более того они для этого и нужны т.я именно на интерфейсах строится контракт между сервисами
Видос классный, очень полезный для меня, подписался. Только, на мой взгляд, во второй половине ты слишком углубился в объяснение ддд. Возможно стоило рассказать с мыслью о том, что мы знаем что это, а для тех, кто не знает записать отдельное видео. Спасибо
Спасибо, рад что видео оказалось полезным. Думаю не все кто посмотрит знает про ддд и чистую архитектуру, хотелось чтобы по просмотру не оставалось много вопросов)
Структура папок в проекте вторична. Главное это разделение ответственностей и связи между компонентами. Если они будут организованы хорошо, то большой разницы куда положить файлик не будет. Куда-то чуть более удобно, куда-то чуть более привычно.
Хм хм, а если мы в cmd хотим запихнуть ещё один проект с main. То для этого нового проекта, где будут храниться пакеты? Видимо так же в internal и pkg. И получается некоторые пакеты используются совместно двумя проектами, некоторые пакеты уникальны для одного проекта. Так как же разрабу понять, какие куда относятся и можно ли что-то поменять для одного проекта и при этом не сломать другой? Вот этого я не понял.
Спасибо, очень интересный материал! Максим, будем очень благодарны, если опубликуешь в гитхабе проект с подобной структурой. Очень хочется поиграться и изучить подробнее.
Спасибо, полезная информация. У меня есть пара вопросов: 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
Супер Макс. Хотелось бы потом по этому проекту, хотя бы в простой версии увидеть курс. Интересно как ты изначально настраиваешь проект, папки, структуры и тд. Также интересно было как ты настроил свой Goland, какая тема, какой шрифт
Golang у меня стандартный) Только немного хоткеи под себя настроил. На канале скоро будет курс по телеграм боту с нуля, там все эти моменты будут разобраны)
Есть подход с генератором проектов. Можно написать утилиту, которая сразу создаёт нужные папки/файлы, прописывает везде всё нужное. Но это актуально если веб-приложения (микросервисы) однотипные по структуре и их много.
Владимир, материал книги уже почти готов, однако в процессе работы я решил дополнить текст дополнительными видеоуроками. По итогу весь этот проект перерос в полноценный курс. Сейчас я активно работаю над платформой, на которой будут опубликованы "Язык Go Для Начинающих" и "Архитектура Современных Веб-Приложений". Платформа позволит безболезненно обновлять и дополнять материалы курса, а также предоставит более удобный формат для его прохождения. Подробную информацию я скоро сообщу в email-рассылке для всех, кто скачал первую главу.
Спасибо! Очень полезное видео. Когда только начинал погружаться в язык (думал сделать его основным перейдя с php), было не понятно как структурировать проект. Много информации было перелопачено. Я так же нарывался на этот репозиторий с бест практисами для структурирования приложения. Здесь же, при просмотре видео, все стало более чем понятно!
@@MaksimZhashkevych скажи пожалуйста, как корректно назвать такую архитектуру. Т.е. ты в видео озвучил, что есть архитектура flat. А как корректно назвать архитектуру, которую ты используешь в видео?
Про репозитории интересно , пойду смотреть еще видео, реально примеров адекватных по работе с бд нет и разделение удачное по моделям / сервисам / репозиториям. Еще нет видоса хорошего по graphql
Вот в том же репозитории есть ссылки на видосы по архитектуре, советую глянуть. Там подробно рассматриваются разные подходы. Начиная с плоской и заканчивая хексагональной с группировкой по функционалу
Спасибо огромное за видео, сам пишу также проекты (не только на GO) с применением Чистой Архитектуры. Хотел бы у тебя узнать, почему у тебя интерфейсы слоя Repository зависят от примитивов MongoDB типа primitive.ObjectID? Интерфейсы Repository должны быть более абстрактными и не привязываться к деталям реализации. В случае, если придется заменить источник данных, например, на Postgres возникнут проблемы. Думаю, лучше было бы заменить primitive.ObjectID на какой-нибудь string, а внутри уже конкретной реализации, в твоем случае MongoDB, преобразовать string в primitive.ObjectID.
Если спустя полгода-год работы над проектом прийдется заменить Mongo на Postgres, то ObjectID в интерфейсах будут самой незначительной проблемой))) Спасибо за отзыв, рад что видео оказалось полезным
Это нормально, что у нас service зависит от структуры Repositories и хэндлер от структуры Services? Там конечно содержатся интерфейсы как поля, но все же это не нарушение Clean Architecture? Это удобно конечно, но не лучше ли такие dependency injection проводить с мэина? например сохдать десять репозиториев и уже их запихнуть в сервис напрямую и то же самое с хэндлером? Тогда получится куча репозиториев и куча стуктур сервисов вместо одного, но не будет ли так правильнее?
Посмотрел курс по RestAPI и вернулся сюда, todo буду переносить на эту структуру, заодно и отточу понимание что и как программировать на go. Я загорелся желанием уйти от php и забыть его как страшный сон )
@@kyleRQWS Не совсем понимаю, в чём проблема с именами этих обёрток? они вполне себе заимствованы из библиотек С. Разве Go отличается каким-то особенно отточенным и выверенным неймингом?
А можешь посоветовать какую-нибудь библиотеку для работы c Excel (XLSX) открытие/редактирование/запись, но чтобы она работала на старой версии 1.10 Не могу найти...
А причем тут DDD и язык? DDD это не про язык и не про программирование, это проектирование. Реализовать можно на любом языке язык это инструмент. DDD это про архитектуру6 фундаментальные принципы проектирования сложных систем, например такой фундаментальный шаблон как Единый Язык это не про программирование.
Я искал подобную информацию во множестве видео, но во всех оказались какие-то онлайн-школы. Что ж, тут по крайней мере не попытались впарить промокод да и сама школа всего лишь в коде. Так что с моей точки зрения - одобрено
Путь "internal->delivery" я бы переименовал в "internal->transport". Вы ведь так и называете его на русском. Потому как слово "delivery" имеет смысл "доставка", как доставка пиццы, в одну сторону - по направлению к объекту получателю.
Да. Пример: "pkg/auth", если ссылки на хаб нету, он в корне проекта ищет директорию pkg и в ней пакет auth. Поиск не относительно исполняемого файла, а от корневого каталога - это важно.
У вас на гитхаб, в том проекте который вы позиционируете как клин архитектур, нет папки internal, это нищетово, мне хотелось посмотреть как вы с ним работаете.
Очередной недо-DDD/clean architecture. Переименуй entity в model и не путай людей. У тебя там сейчас описаны типичные модели ничего не имеющие общего с entity. Возможно, что-то поменяется когда начнёшь писать тесты, но пока это Франкенштейн какой-то. Например, как минимум entity вообще ничего про JSON и как они представлены во внешних слоях знать не должны. И методов там кроме доменной (бизнес) логики никаких не должно быть.
Звучит все очень хорошо, но есть ли хорошие примеры в публичном доступе? Сколько не пытался в "правильное DDD", выходит только хуже. По итогу возишься с мапперами больше, чем работаешь над реальными задачами.
Так как по 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
Решил погрузится в го (по работе хотелось бы переписать один небольшой специфичный микросервис с ноды) обычно я стараюсь следовать стайлгайдам конкретных технологий, но, блин, почему в Го так любят все сокращать, переменные из двух букв, обрубленные слова, котрые часто вижу в исходниках библиотек (например, pkg - вместо package, sk - вместо signingKey, sd - вместо seed, h - вместо handler) и тд Это реально так приянто в Го или мне просто такой код попадается странный Дичь же полная, программы люди же читают, зачем символы экономить, жертвуя читабельностью?)
Есть такое. В стандартной либе тоже такая фигня. Напр. в функции могут встретиться переменные n, s, t и nn, и хер разбери, что они значат. Сам я нарушаю эти правила и пишу без сокращений.
Писал отзыв развернутый и текст изчез. Коротко, инверсия зависимостей и внедрение зависимостей это разные вещи. У вас в проекте нет инверсии зависимоетей, и буква D в SOLID не соблюдается.
Я показал работодателю что я проактивный, могу быстро учить новое, имею дикое желание развиваться как специалист. Также было плюсом что я до этого уже работал в 16 веб-разработчиком, а также у меня был профиль на фрилансе с 6 положительными отзывами. Ну и я выполнил 2 тестовых задания на Go, которые мне скинули)
@@MaksimZhashkevych А щас вы также работаете Go Backend разработчиком?) Спасибо за ваши видео, они помогают, надеюсь их будет больше и они будут полными , то есть front + back + docker + db и т д)
Чем огорчают нынешние детки, сразу оговорюсь, что не все - мы уже все знаем и все умеем. 10К часов или 10 лет никто не отменял, вместо того, чтобы пачкать мозги другим нужно ботанить это время
Нет ни одной причины повторять информацию в видео несколько раз. Понятнее от этого не становится, только раздражает. Видео можно перематывать, если захочется послушать еще раз.
Не понял.. в чем прикол? этот проект можно куда проще реализовать на любой адекватной срм symphony, laravel, typo3.. да хоть самому с 0 написать.. Зачем использовать для этого GO? Создать новый язык что бы что? писать сайты??))
Обновленное видео 2022 - ua-cam.com/video/mesl2Si6saw/v-deo.html
то есть это можно не смотреть?
мне кажется совсем другой человек 2021 - 2024
Путаете немного Инверсию зависимости(DIP) и Инъекцию зависимости(DI). Вообще названия не удачные поэтому путаница возникает между Инверсией зависимости, Инъекцией зависимости, Инверсией Управления. А так же Repository выродился в Gateway. Домен выродился в Анемичную Модель, то есть модель без поведения. Интерфейсы немножко пухловаты для инверсии, и лежат не на том слое, но шаги в правильном направлении, я уж так, придирки)) А вообще Вы молодец что просвещаете народ!
Согласен, сложно смотреть когда понимаешь паттерны и думаешь де блин)
@@hedinsss а какие именно тут паттерны?
@@Levelord92 еврейские
Спасибо тебе, мужик! Было капец как полезно! Я сейчас на стажировке и мне остро не хватало как раз таких разъяснений "по полочкам"
Спасибо большое за видео, очень рад что нашёл ваш канал) продолжайте в том же духе!
Это если не лучший, то один из лучших каналов по данной тематике на русскоязычном ютубе 🔥
Огромное спасибо за это видео, долго не мог понять из статей как грамотно орагнизовать структуру проекта. Было бы круто, если бы ты записал более подробное видео по чистой архитектуре и по чистому коду, в частонсти про SOLID в го. Есть масса статей, но они как правило очень поверхностно описывают эти принципы.
насколько я слышал в го нет классического ооп, но есть свои подобия
На юдеми курс golang-ninja от максима. И там есть глава чистая архитектура. Как раз перед этой главой шла часть с ссылкой на этот видосик
Спасибо огромное! За моими плечами только один очень редкий фреймворк, для которого структуру мы разрабатывали сами. Так как я сейчас изучаю go, было очень интересно сравнить и сопоставить мои знания с новыми.
О пожеланиях: было бы здорово на вашем канале посмотреть как на Го работать с брокерами сообщений (Кафка, Раббит)
Спасибо за идею, учту!
Супер, молодец, удачи тебе!
как пинок в правильном направлении, зачёт.
Ух, сколько связей и переплетений)
А я только на начале изучения языка Go, а здесь уже проект! интересно было просмотреть структуру, что-то думаю поймется со временем. Спасибо!
Я снова влюбился в go и спасибо за инфу про организации приложения!
Спасибо! Весьма и весьма полезно.
Отличное видео. Спасибо!
очень интересная структура! Большое спасибо!
как же ты по красоте делаешь
Спасибо что делитесь опытом. Имхо подход Feature by package самый топовый подход который подойдет для всех видов приложений
Сначала делим на бизнес логические сущности (модули)
user
profile
payment
cart
А дальше в каждой папке будет
user
->features
->login
-> repositories
-> services
-> forms
По гуглю по читаю, спасибо. Сам вот делаю первые шаги в go, до этого немного писал на python
У тебя очень быстро части нижнего слоя окажутся нужны в других фичах и начнётся путаница с тем, где что хранить.
@ если такое случиться тогда ты что то делаешь не так 100%
насколько я знаю, в GO принято объявлять интерфейсы в местах использования, а не рядом с имплементацией. Тут же всё наоборот (например, в папке репозитория).
абсолютно верно!
все верно, так уж пошло на этом проекте) новые стараюсь писать следуя этому принципу
(Совершенно искренний вопрос): А можно тему поподробнее раскрыть, с примером и объяснением "почему". И что делать, если интерфейс используется в нескольких местах?
@@vadimadamlyuk7487 Go отличается по работе с интерфейсами от других языков, где обычно есть что то типа implement, в таких случаях мы должны декларировать интерфейс до использования, в случаи с go, нам не нужно явно имплементировать интерфейс, мы можем работать со структурой а только потом назначить для нее интерфейс, это и есть основный смысл держать интерфейсы ближе к имплементации. А экспортить интерфейсы нам не кто не запрещает, и более того они для этого и нужны т.я именно на интерфейсах строится контракт между сервисами
оооо) реализация ddd в go) интересно, интересно)
Спасибо друг! :) Стало все намного понятнее.
Личные ключи в головном readme - это, конечно, сильно! ;-)
Спасибо, тоже про di заметил. Почитал повторил
Классно объясняешь, спасибо)
офигеть насколько это сложно, но красиво..
Видос классный, очень полезный для меня, подписался. Только, на мой взгляд, во второй половине ты слишком углубился в объяснение ддд. Возможно стоило рассказать с мыслью о том, что мы знаем что это, а для тех, кто не знает записать отдельное видео. Спасибо
Спасибо, рад что видео оказалось полезным.
Думаю не все кто посмотрит знает про ддд и чистую архитектуру, хотелось чтобы по просмотру не оставалось много вопросов)
Очень полезное видео, спасибо
Ахренеть, как круто и доступно объясняешь :) спасибо!
Структура папок в проекте вторична. Главное это разделение ответственностей и связи между компонентами. Если они будут организованы хорошо, то большой разницы куда положить файлик не будет. Куда-то чуть более удобно, куда-то чуть более привычно.
Отличное видео. Спасибо. Создай видео как работать со Swagger. Так как ты умеешь. Четко, без воды и по существу )).
Уже записано, скоро будет на канале)
Супер видео!!!
Давай еще)))
Крутой канал. Продолжай пожалуйста
Все супер, единственное было бы хорошо если нижнюю часть экрана не обрезали. К примеру терминал был не полностью виден.
Благодарю за информацию!
Хм хм, а если мы в cmd хотим запихнуть ещё один проект с main. То для этого нового проекта, где будут храниться пакеты? Видимо так же в internal и pkg. И получается некоторые пакеты используются совместно двумя проектами, некоторые пакеты уникальны для одного проекта. Так как же разрабу понять, какие куда относятся и можно ли что-то поменять для одного проекта и при этом не сломать другой?
Вот этого я не понял.
Нормально чел базаришь, в твоих звуках есть слова, да, я думаю ты шаришь, своими роликами знания подаришь
Отличный видос!
Спасибо, очень интересный материал! Максим, будем очень благодарны, если опубликуешь в гитхабе проект с подобной структурой. Очень хочется поиграться и изучить подробнее.
какой смысл в /internal/, если там код для приложения, но его нельзя использовать (он НЕ клонируется)?
Спасибо, полезная информация. У меня есть пара вопросов:
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 интересно конечно писать интерфейсы для тестов))
Супер Макс. Хотелось бы потом по этому проекту, хотя бы в простой версии увидеть курс. Интересно как ты изначально настраиваешь проект, папки, структуры и тд. Также интересно было как ты настроил свой Goland, какая тема, какой шрифт
Golang у меня стандартный) Только немного хоткеи под себя настроил.
На канале скоро будет курс по телеграм боту с нуля, там все эти моменты будут разобраны)
Есть подход с генератором проектов. Можно написать утилиту, которая сразу создаёт нужные папки/файлы, прописывает везде всё нужное. Но это актуально если веб-приложения (микросервисы) однотипные по структуре и их много.
Спасибо за видео !
Спасибо за ключи, генерировать заново не обязательно ;)
😂😂
Если у вас один main, имхо не нужно создавать cmd, т.к. смысл доп усложнения структуры папок в том, чтобы решить задачу разделения мейнов.
Фоновая музыка иногда сливается с речью и мешает восприятию, убавьте 🙏
Классная подача и подробный разбор тем, лайк!
Спасибо за материал. Просто уточнение - инверсия и внедрение зависимостей это разные понятия.
Когда планируется релиз книги "Архитектура Современных Веб-Приложений" ?
Владимир, материал книги уже почти готов, однако в процессе работы я решил дополнить текст дополнительными видеоуроками. По итогу весь этот проект перерос в полноценный курс.
Сейчас я активно работаю над платформой, на которой будут опубликованы "Язык Go Для Начинающих" и "Архитектура Современных Веб-Приложений". Платформа позволит безболезненно обновлять и дополнять материалы курса, а также предоставит более удобный формат для его прохождения.
Подробную информацию я скоро сообщу в email-рассылке для всех, кто скачал первую главу.
С таким кодом это будет натуральная диверсия. Какие книги могут быть у пионеров? Вопрос риторический
Большое спасибо за видео и за код, очень важно что такие люди как вы открывают код в опенсорс и показывают как "правильно" создавать проекты
Браво, хороший разбор, DI (e.g. Wire) не пробывал?
Спасибо! Очень полезное видео. Когда только начинал погружаться в язык (думал сделать его основным перейдя с php), было не понятно как структурировать проект. Много информации было перелопачено. Я так же нарывался на этот репозиторий с бест практисами для структурирования приложения. Здесь же, при просмотре видео, все стало более чем понятно!
Очень рад что видео оказалось полезным!
Спасибо за видео. Только если возможно, то хотелось бы крупнее шрифт в ide.
Спасибо, учту!
спасибо за видео, если возможно пожалуйсто увеичивайте шрифт в редакторе и по возможности названия папок со шрийтом побольше. в любомслучае спасибо
Интересно) Можно пожалуйста увидеть инверсию зависимостей? Почему domain? просто у меня идут какие-то недопонимание. Почему изначальное не http2?
Domain - от подхода DDD(Domain Driven Design).
Вопрос про http не совсем корректный. Пакет v1 предназначен для инициализации группы эндпоинтов /api/v1
очень хороший контент! спасибо за проделанную работу!
Вопрос : какой опыт работы с Go и в целом программистом?
Спасибо за отзыв!
Программирую еще с детства, на первую работу веб-разработчиком устроился в 2016-ом, с Golang работаю с начала 2018-го
А как организованы Unit тесты в проект на Go?
Максим, сделай пожалуйста курс по Kafka
Очень классно объясняешь, спасибо)
Спасибо за отзыв! стараюсь)
Спасибо, хорошо описано. Я аналогично пишу.
Хотелось детальней взглянуть на репозиторий. Ссылочка есть?
Да, проект в открытом доступе на моем Github:
github.com/zhashkevych/courses-backend
@@MaksimZhashkevych thanks
@@MaksimZhashkevych скажи пожалуйста, как корректно назвать такую архитектуру. Т.е. ты в видео озвучил, что есть архитектура flat. А как корректно назвать архитектуру, которую ты используешь в видео?
@@vladimireliseev7602 clean architecture
Про репозитории интересно , пойду смотреть еще видео, реально примеров адекватных по работе с бд нет и разделение удачное по моделям / сервисам / репозиториям. Еще нет видоса хорошего по graphql
Вот в том же репозитории есть ссылки на видосы по архитектуре, советую глянуть.
Там подробно рассматриваются разные подходы. Начиная с плоской и заканчивая хексагональной с группировкой по функционалу
Спасибо огромное за видео, сам пишу также проекты (не только на GO) с применением Чистой Архитектуры. Хотел бы у тебя узнать, почему у тебя интерфейсы слоя Repository зависят от примитивов MongoDB типа primitive.ObjectID? Интерфейсы Repository должны быть более абстрактными и не привязываться к деталям реализации. В случае, если придется заменить источник данных, например, на Postgres возникнут проблемы. Думаю, лучше было бы заменить primitive.ObjectID на какой-нибудь string, а внутри уже конкретной реализации, в твоем случае MongoDB, преобразовать string в primitive.ObjectID.
Если спустя полгода-год работы над проектом прийдется заменить Mongo на Postgres, то ObjectID в интерфейсах будут самой незначительной проблемой)))
Спасибо за отзыв, рад что видео оказалось полезным
Это нормально, что у нас service зависит от структуры Repositories и хэндлер от структуры Services? Там конечно содержатся интерфейсы как поля, но все же это не нарушение Clean Architecture? Это удобно конечно, но не лучше ли такие dependency injection проводить с мэина? например сохдать десять репозиториев и уже их запихнуть в сервис напрямую и то же самое с хэндлером? Тогда получится куча репозиториев и куча стуктур сервисов вместо одного, но не будет ли так правильнее?
Посмотрел курс по RestAPI и вернулся сюда, todo буду переносить на эту структуру, заодно и отточу понимание что и как программировать на go.
Я загорелся желанием уйти от php и забыть его как страшный сон )
Чего страшного в пхп?
@@xbsxbs22 страшного ничего нет, а вот атавизмы из-за его возраста присутствуют.
@@kyleRQWS Какие к примеру?
@@xbsxbs22 Функции str_* и с иным форматом наименования strstr strpos, file_exists и filesize.
@@kyleRQWS Не совсем понимаю, в чём проблема с именами этих обёрток? они вполне себе заимствованы из библиотек С. Разве Go отличается каким-то особенно отточенным и выверенным неймингом?
А можешь посоветовать какую-нибудь библиотеку для работы c Excel (XLSX) открытие/редактирование/запись, но чтобы она работала на старой версии 1.10
Не могу найти...
Не раз слышал о том что не нужно мешать подходы из Java/C# к Go, и советуют не использовать DDD а использовать обычный go-way.
А причем тут DDD и язык? DDD это не про язык и не про программирование, это проектирование. Реализовать можно на любом языке язык это инструмент. DDD это про архитектуру6 фундаментальные принципы проектирования сложных систем, например такой фундаментальный шаблон как Единый Язык это не про программирование.
Я искал подобную информацию во множестве видео, но во всех оказались какие-то онлайн-школы.
Что ж, тут по крайней мере не попытались впарить промокод да и сама школа всего лишь в коде.
Так что с моей точки зрения - одобрено
Путь "internal->delivery" я бы переименовал в "internal->transport". Вы ведь так и называете его на русском. Потому как слово "delivery" имеет смысл "доставка", как доставка пиццы, в одну сторону - по направлению к объекту получателю.
хорошее замечание, имеет смысл, спасибо
я однажды столкнулся с delivery на одном проекте - так и приелось)
актуальненько :3
А ссылки нет. И, на хабе, также найти не найти данный пример(
Коммент для активности
можно ли в main подключить локальные пакеты без указания пути через github?
Да. Пример: "pkg/auth", если ссылки на хаб нету, он в корне проекта ищет директорию pkg и в ней пакет auth. Поиск не относительно исполняемого файла, а от корневого каталога - это важно.
У вас на гитхаб, в том проекте который вы позиционируете как клин архитектур, нет папки internal, это нищетово, мне хотелось посмотреть как вы с ним работаете.
Все круто🔥, только(!), пожалуйста, называй папки - директориями, а файлы(.go) - пакетами🙏. Удачи в развитии канала🍀
Пакет это не файл, а папка
Что за IDE?
Goland
Мне кажется для веб сервера не походит internal, т.к. такие приложения вряд ли будут импортировать, поэтому защищать от импорта не нужно.
Мне кажется логичнее pkg не использовать в таком случае 😀 а то странно держать бизнес логику в «публичных» пакетах
интерфейс и подсветку vs в goland и было бы зашибись)
Чё 2160p это каК?
При регистрации на твоём сайте получил письмо с битой ссылкой ( текст выделяется, самой ссылки для активации нет )
:)
Проверил, все работает, а подскажи свой email?
@@MaksimZhashkevych botanprog@aol.com
@@MaksimZhashkevych Пользователь с таким email уже зарегистрирован. Если возникли проблемы, напиши мне на zhashkevychmaksim@gmail.com
Красава!
👍
💪👍
а где тесты если это реальный проект? только один увидел, где остальные?
Очередной недо-DDD/clean architecture. Переименуй entity в model и не путай людей. У тебя там сейчас описаны типичные модели ничего не имеющие общего с entity. Возможно, что-то поменяется когда начнёшь писать тесты, но пока это Франкенштейн какой-то. Например, как минимум entity вообще ничего про JSON и как они представлены во внешних слоях знать не должны. И методов там кроме доменной (бизнес) логики никаких не должно быть.
Звучит все очень хорошо, но есть ли хорошие примеры в публичном доступе? Сколько не пытался в "правильное DDD", выходит только хуже. По итогу возишься с мапперами больше, чем работаешь над реальными задачами.
Так как по 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
дякую
я бы использовал DTO.
Решил погрузится в го (по работе хотелось бы переписать один небольшой специфичный микросервис с ноды)
обычно я стараюсь следовать стайлгайдам конкретных технологий, но, блин, почему в Го так любят все сокращать, переменные из двух букв, обрубленные слова, котрые часто вижу в исходниках библиотек (например, pkg - вместо package, sk - вместо signingKey, sd - вместо seed, h - вместо handler) и тд
Это реально так приянто в Го или мне просто такой код попадается странный
Дичь же полная, программы люди же читают, зачем символы экономить, жертвуя читабельностью?)
Есть такое. В стандартной либе тоже такая фигня. Напр. в функции могут встретиться переменные n, s, t и nn, и хер разбери, что они значат. Сам я нарушаю эти правила и пишу без сокращений.
Потому что Амеры любят сокращать, и зык сам не Golang a Go....
Ну какой крон уж?) Тайм тикер есть... А вообще, очень полезное видео!)
Писал отзыв развернутый и текст изчез. Коротко, инверсия зависимостей и внедрение зависимостей это разные вещи. У вас в проекте нет инверсии зависимоетей, и буква D в SOLID не соблюдается.
У меня другая структура а тут даже папки вендора нет)
Макс, расскажи как тебя взяли голанг-джуном когда ты толком не знал языка?
Я показал работодателю что я проактивный, могу быстро учить новое, имею дикое желание развиваться как специалист.
Также было плюсом что я до этого уже работал в 16 веб-разработчиком, а также у меня был профиль на фрилансе с 6 положительными отзывами.
Ну и я выполнил 2 тестовых задания на Go, которые мне скинули)
@@MaksimZhashkevych А щас вы также работаете Go Backend разработчиком?) Спасибо за ваши видео, они помогают, надеюсь их будет больше и они будут полными , то есть front + back + docker + db и т д)
"имеет место", а не "имеет место быть". Второе -- это ошибка.
Я кстати успел поюзать ключи если что
без проблем, проект неактивный уже давно, юзай наздоровье
4-ый раз смотрю это видео полностью уже, каждый раз с пользой. Слава Украине!
Никогда такими шаблонами не пользуйся. То что тут промахивается в видосе, это полная жесть
Эх, хорошие раньше видосы были, сейчас, к сожалению, сплошное водогонство пошло.
эх, как жаль..
Чем огорчают нынешние детки, сразу оговорюсь, что не все - мы уже все знаем и все умеем. 10К часов или 10 лет никто не отменял, вместо того, чтобы пачкать мозги другим нужно ботанить это время
Нет ни одной причины повторять информацию в видео несколько раз. Понятнее от этого не становится, только раздражает. Видео можно перематывать, если захочется послушать еще раз.
Очередной пухлый роман вместо микросервиса
Мляя, без музона слабо????
словно евровидение освещаете...
Не понял.. в чем прикол? этот проект можно куда проще реализовать на любой адекватной срм symphony, laravel, typo3.. да хоть самому с 0 написать.. Зачем использовать для этого GO? Создать новый язык что бы что? писать сайты??))