Пересмотрел предыдущие видео о чистой архитектуре и это видео. Этот вариант намного круче, проще, понятнее и гибче. Сделано более качественно, однозначно лайк👍 Будем реализовывать на практике😊
Выходит, что в Go нет устоявшейся конвенции по логическому разделеню кода на директории/пакеты, как например в Java? Иногда забавно наблюдать за всеми этими метаниями в ролике, в процессе написания кода: "сделаем это здесь... нет, лучше сделаем этот тут или лучше там".
Отличный видос, то что я искал. Только начал изучать чистую архитектуру и меня очень напрягало куча одинаковых интерфейсов в разных папках. Значит я все правильно понял
У тебя не юзкейсы, а коллекции юзкейсов. Юзкейсы - это «предоставить список доступных книг отфильтрованных по X», «выдать книгу пользователю», «получить новую книгу на баланс» и т.п.
Спасибо за видео. А что делать, если этот сервис нужно поднять на сервере в докере? yaml/env/json файлы же не хранят в репозитории? Как тогда задеплоить в gitalb, например ?
Интерфейсы в go вообще не нужны в общем случае. Они объявляются ровно там, где требуется соответствие контракту. Один и тот же сторадж в разных сценариях может удовлетворять разным интерфейсам - один сценарий только создаёт сущности, другой только ищет и т.п. Полный интерфейс всего стораджа не нужен никому.
Эх. Сколько придётся принять антидепрессантов, чтобы из python войти в чистую архитектуру на Golang. Когда на видео эксперт 20 минут тратит на реализацию простейшего казалось бы кейса exlude/include fields. Который по идее должен идти в месте с параметрами функции GetList(limit, offset, include, exclude). Но в Golang нет параметров default у функций вот и появляются всякие встраивания структуры в структуру, которые работают под кейс всё равно, а не ABC. Страшно.
А зачем в entity нужны json-атрибуты. по сути domain вообще не должен знать что такое json? Он должен конвертиться во что угодно соответствующим адаптером (json, sql, xml, proto...)
Наконец-то посмотрел, спасибо, красота какая! Вопрос: а как же интерфейс Сервиса? Разве NewService не должен возвращать именно интерфейс, а не конкретную реализацию сервиса?
@@TheArtofDevelopment на вызывающией конструктор функции я и так принимаю в виде интерфейса. Но сказали что это плохая практика, нужно делать экспортируемым сам тип. Хотя я не понимаю что плохого в таком подходе, Вот и ищу где почитать про самый правильный способ ))
@@cegheyYT Нужно проверить. Например у тебя есть интерфейс, а тебе нужно определить тип и кастануть к нему, если тип не экспортируемый, то не сможешь привести к нему
Зачем разделять dto в http и в service? Они имеют идентичные поля, разница лишь в json тэгах. Они на что-то влияют? Почему нельзя использовать один dto с тэгами на два слоя?
Потому что все адепты чистой архитектуры умалчивают о том как все это дерьмо инитить, а вот тут всплывает все дерьмо которое они так старательно отовсюду вычистили
Вместо того, чтобы просто возвращать 200 с совершенно другой структурой ответа (бедные клиенты), посмотри хотя бы на `Content-Type: application/problem+json` Какая разница, транспорт это или нет. До того как понять, какова схема прилетела в ответе, клиент вынужден как-то распарсить ответ и убедиться, что это не ошибка.. Не надо так.
Какие книги? Какие авторы? Какие модели? Те, которые по подиуму ходят, или те, которые по небу летают? Автор хоть бы 5 секунд потратил на то, чтобы объяснить - об чем тут вообще речь...
@@TheArtofDevelopment Наверное где-то в другом видео, ссылку на которое автор дать забыл. Да Вы просто переслушайте свое видео - там нет никакого объяснения. Сторонний зритель заходит и ощущает себя пришедшим на середину пьесы...
Нельзя не поставить лайк. Много чего уточнил для себя. Спасибо что поделились.
Реально очень чистая архитектура, файл мэин.го из репозитория пустой
А без шуток лучшие уроки по Го - спасибо Артур.
Спасибо, что продолжаете делиться своими успехами.
Спасибо за стрим!
Было бы здорово осветить подробнее тему реализации транзакций в юзкейсах и сервисах на практике.
Пересмотрел предыдущие видео о чистой архитектуре и это видео. Этот вариант намного круче, проще, понятнее и гибче. Сделано более качественно, однозначно лайк👍
Будем реализовывать на практике😊
Teperj nado video - " Samaja chistaja Go arhitektura"! :D
С переделанной архитектурой, теперь должно быть проще тестировать и в целом выглядит прозрачно понятно. Круто организовано - это 𝕃𝕚𝕜𝕖👍
Выходит, что в Go нет устоявшейся конвенции по логическому разделеню кода на директории/пакеты, как например в Java? Иногда забавно наблюдать за всеми этими метаниями в ролике, в процессе написания кода: "сделаем это здесь... нет, лучше сделаем этот тут или лучше там".
Спасибо, супер. Хотелось бы увидеть примеры с транзакциями на разных уровнях.
Как это всё работает, автор конечно же не показал... Ну да, ведь, это совершенно неважно! Чемодан без ручки.
Отличный видос, то что я искал. Только начал изучать чистую архитектуру и меня очень напрягало куча одинаковых интерфейсов в разных папках. Значит я все правильно понял
Как всегда круто. Давай что нибудь на веб сокетах.
как всегда топ!
Смотреть x1.5-x2 :D
и заходим в Телеграмм Канал: t.me/theartofdev
И в Телеграмм Группу: t.me/theartofdevel
Ура!!!
А где-то уже есть отдельное видео о том, чем так плохи указатели?
Если бы в go были константные указатели, ты бы от них не отказался?
У тебя не юзкейсы, а коллекции юзкейсов. Юзкейсы - это «предоставить список доступных книг отфильтрованных по X», «выдать книгу пользователю», «получить новую книгу на баланс» и т.п.
Спасибо за видео. А что делать, если этот сервис нужно поднять на сервере в докере? yaml/env/json файлы же не хранят в репозитории? Как тогда задеплоить в gitalb, например ?
через ENV переменные
почему не создать бы один общий интерфейс и привязывать сторажи к нему? зачем дублирование кода?
Интерфейсы в go вообще не нужны в общем случае. Они объявляются ровно там, где требуется соответствие контракту.
Один и тот же сторадж в разных сценариях может удовлетворять разным интерфейсам - один сценарий только создаёт сущности, другой только ищет и т.п.
Полный интерфейс всего стораджа не нужен никому.
Эх. Сколько придётся принять антидепрессантов, чтобы из python войти в чистую архитектуру на Golang. Когда на видео эксперт 20 минут тратит на реализацию простейшего казалось бы кейса exlude/include fields. Который по идее должен идти в месте с параметрами функции GetList(limit, offset, include, exclude). Но в Golang нет параметров default у функций вот и появляются всякие встраивания структуры в структуру, которые работают под кейс всё равно, а не ABC. Страшно.
нет "тама" исходного кода, он старый
А зачем в entity нужны json-атрибуты. по сути domain вообще не должен знать что такое json? Он должен конвертиться во что угодно соответствующим адаптером (json, sql, xml, proto...)
Думаю сила привычки ;-)
Наконец-то посмотрел, спасибо, красота какая!
Вопрос: а как же интерфейс Сервиса? Разве NewService не должен возвращать именно интерфейс, а не конкретную реализацию сервиса?
нет. принимаем интерфейс а возвращаем интерфейс
@@TheArtofDevelopment очепятка, Accept interfaces, return structs
Про возврат из конструктора неэкспортируемого типа, мне сделали замечание в дипломной работе ((, теперь ищу источник истины ))
а что они предлагают возвращать? интерфейс ?
@@TheArtofDevelopment на вызывающией конструктор функции я и так принимаю в виде интерфейса. Но сказали что это плохая практика, нужно делать экспортируемым сам тип. Хотя я не понимаю что плохого в таком подходе, Вот и ищу где почитать про самый правильный способ ))
@@cegheyYT Нужно проверить. Например у тебя есть интерфейс, а тебе нужно определить тип и кастануть к нему, если тип не экспортируемый, то не сможешь привести к нему
Ну и вообще странно делать тип не экспоритруемым, если предпологается, что он будет использоваться за пределами своего пакета
Зачем разделять dto в http и в service? Они имеют идентичные поля, разница лишь в json тэгах. Они на что-то влияют? Почему нельзя использовать один dto с тэгами на два слоя?
архитектура все еще чистая или уже не очень?
уже не очень. ждите новый ролик.
можешь записать видео с крутыми запросами через select на go
Куда девать контроллеры миддл вари?
в отдельный пакет
@@TheArtofDevelopment
В папке controllers?
Вообще, предложенная архитектура мне очень нравится. Очень лаконично и логично!
Спасибо за отличные уроки по Го. В репозитории примера файл мэйн.го пустой. Так и задумано?
Потому что все адепты чистой архитектуры умалчивают о том как все это дерьмо инитить, а вот тут всплывает все дерьмо которое они так старательно отовсюду вычистили
я не адепт) но проблемы есть везде
А есть какая нибудь такая же крутая архитектура при работе с брокерами типа Кафки?
так архитектура такая же. чтение из кафки - это как веб контроллер, запись в кафку это как слой работы с БД.
@@TheArtofDevelopment понял, спасибо большое)))
Ахтур
Все круто конечно, но смотреть тяжело... Лайф формат классно, но сложно для восприятия.
можно пожалуйста громче
Не понимаю какую роль тут играют сервисы? они же просто вызывают методы репозитория что можно делать и из юзкейсов
там размещаю дополнительную логику по сущности: обогащение, кеш можно туда воткнуть.
Вместо того, чтобы просто возвращать 200 с совершенно другой структурой ответа (бедные клиенты), посмотри хотя бы на `Content-Type: application/problem+json`
Какая разница, транспорт это или нет. До того как понять, какова схема прилетела в ответе, клиент вынужден как-то распарсить ответ и убедиться, что это не ошибка.. Не надо так.
так нет другой структуры. поля error и message парсите всегда и все
Какие книги? Какие авторы? Какие модели? Те, которые по подиуму ходят, или те, которые по небу летают?
Автор хоть бы 5 секунд потратил на то, чтобы объяснить - об чем тут вообще речь...
5 секунд потратил
@@TheArtofDevelopment Наверное где-то в другом видео, ссылку на которое автор дать забыл. Да Вы просто переслушайте свое видео - там нет никакого объяснения. Сторонний зритель заходит и ощущает себя пришедшим на середину пьесы...