Уроки по Golang. Advanced. Чистая Архитектура / Clean Architecture Часть 2

Продолжаем разговор про чистую архитектуру. Вторая часть!
Приятного просмотра!

Больше обо мне и курсах можно прочитать здесь:

GitHub репозиторий:

Поддержи выход новых видео на Патреоне!

Первая часть:

Другие видео:
Уроки по Golang. Advanced. REST API. Вебсервер.

----

На этом канале я выкладываю ролики на интересующие меня темы, здесь можно найти серию роликов про создание информационной системы с нуля, а также можно найти серию уроков по языкам, которые я люблю. Добро пожаловать и хорошего просмотра!

#golang #урок #restapi #rest #микросервисы #microservices #jetbrains #goland #tutorial #голенг #development #howto #learnbasics #coding #programming #изучаемIT #программирование #разработка

[MaximRovinsky]

Такой формат как в этом видео, супер. Не так затянуто получается, нежели писать реализацию прямо в видео. Спасибо за ваши уроки 👍🏼

[devchuli]

15:07 ощущение, что не стоит в api класть интерфейс связано с тем, что метод NewService() в domain/books/service.go не должен возвращать интерфейс book.Service, а должен возвращать указатель на структуру service

[ivanstrelka]

Спасибо, Артур, часть 2 огонь и всё остальное! Кайф!!!

[aidarlatypov]

Ну если уж судя по началу видео, можно замечания оставлять то по занудствую)
- По поводу модели, сначала вроде как правильно начал писать AuthorUUID потом переделал на тип. По хорошему для меньшей связности (если учесть что это веб сервис все таки) и меньшей нагрузки на память. "Ссылайтесь на агрегаты по id"
- В доменных сущностях теги не хорошо, сущности должны быть чистыми
- По домену и размазыванию логики. Тут нужно смотреть в подобласти домена и выделять ограниченные контексты, сейчас есть перетекание в уровень usecase /interactor в Вашем случае это называется просто по другому service. Чистая архитектура не спасает от спагетти в домене.
- Интерфейс сервиса это первичный порт, он правильно лежал!!! Первичные порты лежат около реализации! И это один из немногих случаев когда интерфейс лежит около реализации. "A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions." Вторичные порты лежат где используются так как инвертируют зависимость. Правильно ощущение. что не надо туда класть!
- По хорошему юзкейсы/интеракторы должны быть по одному на действие, да тут можно этим принебречь конечно, но именно такие интеракторы приводят к максимально компактным интерфейсам, а это go way когда интерфейс это один два метода.
- По неймингу. В домене нужно избегать технических названий, что такое UUID для домена? Лучше заменить в домене на просто ID (распространное в англоязычной мире понятие) UUID это уже по сути введение домена в технические детали. Если прямо чтоб по красоте было заменить на ISBN что есть уникальный идентификатор книги учитывая Вашу модель.
- По неймингу еще в интеракторах. то есть в данном случае в сервисах не желательно использовать такие названия как GetByUUID они не несут смысла в уровне usecase, по идее должно называться CheckAuthorExists потому, что в случае изменения уровня хранения на реляционную бд может и не быть никаких uuid, то есть в уровне usecase должны быть осмысленные имена, описательные
- Спорный момент по вызову одного Интерактора из другого, это получается зависимость, правильно что не нравится) если делать по красоте, то есть как выше писал варианты использования отдельные, то будет так что один юзкейс не зависит совсем от других, то есть более безопасно вносить изменения. Я бы рекомендовал вызовы уровня одного слоя делать на слое доступа к данным, так фактически достигается высокое зацепление, одноуровневых компонентов и низкая связность вариантов использования. А именно в этом заключается смысл чистой архитектуры.
- Последняя проблема мне кажется немного надуманно, можно же поменять псевдонимы на описательные, main компонент самый грязный и там можно писать что то типа book repo, book controller и тд Ну да придется немного поработать клавиатурой, но чистая архитектура в принципе на избыточности построена, но в целом тут уже каждому свое по этому пункту)

Не ради критики, а истины для. Добра!!

[javascriptprisoner]

Мне больше нравится формат кодинга не за кадром. Видео супер, спасибо!

[delay_gryaz_chisto]

стрим было бы здорово) только заранее забиться на время бы)
по части интерфейса рядом с апи - вроде и правильно, что интерфейс лежит там, где используется, но с другой стороны: появится адаптер под cli - и что делать?) дублировать код что ли?) не по-пацански это)
может стоит положить его в отдельный файл interfaces в пакете adapters?

по части дальнейшей жизни проекта:
я думаю, было бы здорово сделать это на псевдокоде с элементами го. то есть не использовать бд - использовать мапу. написать хттп сервер, и пару ручек для каждой сущности. ну и продемонстрировать как куда бегут данные, для чего дто, где как это все перетекат и тд. я это вижу так. упарываться прям в написание sql, или еще чего - лишнее в данной серии видео. главное же суть понять.

ну и да, голанд умеет генерить конструкторы по alt+enter на структуре (:

спасибо большое за видео!

[Shindos-Kopernik]

Для новичка сложновато, но очень интересно!
Хочется смотреть еще и еще!
Отличные ролики.

[ashtangacenterodessa]

И с супернетерпением жду продолжения видео по рест апи, с использованием самых хайповых, и не очень), технологий из гошного стека : Kafka, gRPC, PostgreSQL, Jaeger, Prometheus, Grafana и т.д

[stiker]

Крутой формат, хорошо будет когда, сразу в видео пишешь

[КириллВерховский-ыш]

Очень классные уроки, на многое открыли глаза. Продолжай в том же духе!

[АлександрРыков-жы]

Удобно реализацию за кадром в git, а потом просто стреми пользоваться checkout

[slavik]

все четко, спасибо!
по поводу кодинга можно стрим с лайвкодом, если есть время, а если нету то лучше за кадром

[dm.rusakov]

I think livetime coding and your comments give to me more opportunity understand project. And I can type code this you. It is some additional expiriens too.
And, maybe, you can add an application structure picture like on first video notes system. It gonna be helpful understand project.

PS! thank you! you are The Man!

[theeasywaytr]

Добрый день! Я не понял логику, почему мы в адаптере ссылаемся на интерфейс Storage, который в domain - вроде как в конкретном бизнес-кейсе? А вот с сервисом наоборот получается.

[metallizer]

Я всё-таки не понял с этим интерфейсом Service. Получается вообще так, что он лежит в слое Controllers, но так как мы используем этот интерфейс в Domain, то получается нарушение зависимостей, так как Domain вообще не должен знать о том, что находится на более высоких уровнях, разве не так?

[vp_arth]

В прошлой части User был не автором, а посетителем библиотеки. Когда заносили Age, оговаривалось, что это для авторизации по возрасту.

[ЕвгенийБорзов-бк]

а разве нормально что возникает круговая зависимость? модуль api/author ссылается на domain/author и наоборот domain/author ссылается на api/author ??

[TheAgathoDaemon]

Отличные ролики, спасибо огромное за труды! Будет ли учтена возможность версионности хендлеров?

[zhaisan]

какой клавишой вы делаете равномерный отступ json в модельках?

[rumartru]

На мой взгляд лучше записать, а потом объяснять. А то лайвкодинг получается с ошибками, сначала запоминаешь одно, потом оказывается, что так делать не надо... немного сбивает) И по продолжительности ролик занимает больше времени.