Тёмный

Архитектура Go проекта на практике 

Evrone Development
Подписаться 9 тыс.
Просмотров 13 тыс.
50% 1

Подписывайтесь на наш канал здесь и в телеграмм t.me/meetups_evrone, чтобы быть в курсе будущих митапов и не пропускать полезные доклады!
Полная трансляция митапа - • Evrone Golang meetup
Тигран Ханагян / HungerStation Delivery Hero
00:00 - Введение
01:00 - О чем будем говорить?
01:55 - Инфраструктура и бизнес логика
06:58 - Проблемы
07:52 - Как решить эти проблемы?
08:00 - Чистая архитектура
14:59 - Dependency inversion principle
15:44 - Нейминг в Go
16:14 - Use case
17:45 - Adapter
18:57 - Handler
20:22 - Библиотека Goro: как её использовать
Тигран Ханагян рассказывает о реализации чистой архитектуры на Golang и показывает, как это работает на практике. За годы работы на разных проектах автор сформировал для себя набор практик для построения чистой архитектуры кода и оформил это в виде инструмента для кодогенерации. В докладе он делится основными моментами, на которые стоит обратить внимание при написании чистого кода на Go, рассказывает о своих предпочтениях и аргументирует это примерами из практики. С помощью генератора кода он создаст проект, на котором и продемонстрирует полезность подхода чистой архитектуры в Go-приложении.

Наука

Опубликовано:

 

29 июн 2024

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 40   
@nikitajolobov4591
@nikitajolobov4591 3 месяца назад
большое спасибо за доклад, все кратко по дело. Отдельное спасибо за пакет goro
@dmitriyosin8528
@dmitriyosin8528 Год назад
Спасибо за видео!
@EvroneDevelopment
@EvroneDevelopment Год назад
Рады стараться!
@Elteruin
@Elteruin 8 месяцев назад
Крутой доклад.
@mnogokotin
@mnogokotin 10 месяцев назад
спасибо за видео
@EvroneDevelopment
@EvroneDevelopment 9 месяцев назад
Рады что вам понравилось!
@user-bh8xz4xy7o
@user-bh8xz4xy7o 8 месяцев назад
Гений!!!
@aleksandrpetrov3938
@aleksandrpetrov3938 Месяц назад
13:50 - если в "слое сервисов есть несколько пакетов, и они могут вызывать друг друга", получится циклический импорт же :(
@waffleboot
@waffleboot 8 месяцев назад
Хороший доклад, мы к такому же пришли, ну точнее чел с опытом в DDD нас направил на путь истинный. Единственно не стали сильно глобалить entity чтоб аж json в них прописывать. И usecase у нас может работать с репо. Зачем писать service для get-ручки? Handler вызывает facade, facade вызывает usecase или facade может сам в репо сходить. Хотя это вопрос конечно как логику приложения делить между usecase и service. Ну и не пишем в каждом сервисе interface для репо из одного метода. Репо-интерфейсы вынесены в порты (архитектура порты & адаптер) и каждый сервис импортит порт. А если нужен все таки интерфейс для сервиса, то у нас он exported, а не внутренний для пакета. Когда интерфейс с lower case именем понятно что он под внутренние цели. Но у нас они в upper case как признак того что это внешняя зависимость.
@ntldrzic
@ntldrzic 3 месяца назад
спасибо за свой опыт. Можно ли указать какой-либо публичный репозиторий, чтобы посмотреть это в коде?
@redneck_prm5429
@redneck_prm5429 Год назад
А ведь каких-то лет пять назад гошники при упоминании чистой архитектуры начинали шипеть что-то вроде "валите обратно в свою жабу". Глобальные entity дабы не делать dto - может и имеет право на жизнь. Но всё-таки идея перекидывать между слоями определенные data structure несет не только изоляцию слоев, но и возможность эти самые ds кастомизировать под необходимости конкретных слоёв. entity всёж по определению предельно чисты и не содержат ничего от следующих слоёв.
@TheDavBag
@TheDavBag 11 месяцев назад
есть N слоёв и M сущностей с мапингом при каждом переходе из слоя в слой. Много ли будет накладной и, скорее всего, бесполезной работы?
@redneck_prm5429
@redneck_prm5429 11 месяцев назад
@@TheDavBag Идеологи чистой архитектуры открыто пишут, что она стоит заметных дополнительных затрат и бездумно совать ее куда попало не стоит.
@TheDavBag
@TheDavBag 11 месяцев назад
@@redneck_prm5429 да, и насколько мне известно, ЧА создавалась для решения задач модульного монолита
@evgeniybudaev1690
@evgeniybudaev1690 5 месяцев назад
Доклад вроде бы хороший, но мне как новичку без наглядного работающего кода не понять что и как между собой взаимодействует
@user-em2jh9pi3i
@user-em2jh9pi3i 3 месяца назад
Спасибо за классный доклад. Можно где-то презентацию скачать?
@user-fh6xg9pn3y
@user-fh6xg9pn3y 9 месяцев назад
Начал за здравие, кончил - за упокой) Про глобальные entity. С одной стороны верно, т.к. главное правило зависимостей соблюдается. Т.е. есть центральные бизнес-сущности (entity), которые не зависят ни от чего. А репозитории и контроллеры - зависят от них. Зря не любишь круглую диаграмму. Если на ней нарисовать стрелки зависимостей, то увидишь, что все стрелки идут в центр. Т.е. переферия зависит от бизнес-ядра. DTO для того и нужно, чтобы укоротить стрелки, чтобы разорвать зависимость между ядром и контроллером. Вот ты у entity переименовал поле или удалил. И сигнатура АПИ тут же ломается. Между ними как раз должен быть промежуточный DTO, который на себя возьмёт роль поддержания совместимости. Вот там нормально выглядят json теги.
@EvroneDevelopment
@EvroneDevelopment 9 месяцев назад
Не стоит быть столько критичным ;)
@user-fh6xg9pn3y
@user-fh6xg9pn3y 9 месяцев назад
@@EvroneDevelopment Не стоит быть таким душнилой, Вы хотели сказать наверное 😂
@akhmetgareev
@akhmetgareev 6 месяцев назад
это еще добавит слой мапперов из дто в ентити и обратно + тесты. зависит от размера проекта конечно, но если это сервис ближе к микро, чем к макро, то имхо подход Тиграна сильно упрощает. Особенно учитывая что там и так достаточно много бойлерплейта, особенно на этапе инициализации. В авито плюс-минус к тому же пришли в итоге. Удобно, особенно покрывать тестами каждый слой независимо
@rostislavteryaev3894
@rostislavteryaev3894 8 месяцев назад
Но хэндлер это же тоже адаптер)
@gooseman5578
@gooseman5578 6 месяцев назад
а чего без github-а то? :(
@TheDavBag
@TheDavBag 11 месяцев назад
paymenter userer subscripter =) думаю, можно обойтись без usecase, а может даже без service также, я бы не советовал писать сущности с экспортируемыми полями - это ломает инкапсуляцию поведения
@user-ps6bb1fm9u
@user-ps6bb1fm9u 10 месяцев назад
Ломает да, только в Go от этого никуда не денешься, т.к. не сможем анмаршалить/маршалить структуры из/в json/db/... По этому как было сказано в видео можно городить всякие мапперы,гидраторы и прочие преобразователи.
@TheDavBag
@TheDavBag 10 месяцев назад
@@user-ps6bb1fm9u не ломает, надо просто имплементировать Unmarshaller
@alex-0x6b
@alex-0x6b 9 месяцев назад
Называя папку usecase вы жестко привязываетесь к дядюшке Бобу, а оно вам надо?) Считаю это определение максимально неудачным.
@EvroneDevelopment
@EvroneDevelopment 9 месяцев назад
У каждого свой путь ;)
@user-fh6xg9pn3y
@user-fh6xg9pn3y 9 месяцев назад
Нормальное название) Зато понятно о чём речь!
@alex-0x6b
@alex-0x6b 9 месяцев назад
Я решил добавить чучуть больше аргументов против использования термина usecase (случай использования или пользовательский случай). Боб просто обобщил бизнес-логику назвав это usecase, но такое определение в коде делает его сильно шаблонным. Не знаю, может у меня просто такое отношение, ведь мне кажется логичнее назвать это, ну скажем, хотябы domain. Простите за занудство, ведь мы все прекрасно знаем, что на названия программист тратит 90% времени. 😀
@user-fh6xg9pn3y
@user-fh6xg9pn3y 9 месяцев назад
@@alex-0x6b Есть чёткое ощущение, что Вы неверно понимаете Чистую Архитектуру и понятие "usecase" в частности. По-русски это будет "Вариант использования", а по смыслу "Бизнес-правила, связанные в конкретным приложением". "domain" - это неверное название (неконкретное). Пример: у вас служба записи к врачу. 1. Критические бизнес-правила (самое ядро, сущности, entity) - это про врачей, пациентов, болезни и график работы. Т.е. то, что существует без всяких приложений. Эти сущности из реального мира, они существовали еще когда не было никакого интернета. 2. usecase - Это то, что связано с конкретным приложением. Например, процедура регистрации на сайте через веб, отображение информации о враче на одной карточке вместе с фоткой. Это то, что вроде как рядом с "доменом", но чётко завязано на конкретное веб-приложение. Мобильное приложение для записи к врачу - это второй usecase, у него и процедуры регистрации другие, и протоколы и форматы данных и т.д. "Доменом" обычно называют эти две области вместе. Либо критические бизнес-правила плюс небольшая часть из usecase.
@Aaaa-jn4bm
@Aaaa-jn4bm 7 месяцев назад
Usecase - это буквально переводится как бизнес-сценарии, самое подходящее название. Ниже вы предложили domain.. domain - это буквально предметная область, название не передаёт прямой сути (как и "сервисы")
@user-zg8ij3kt1h
@user-zg8ij3kt1h 9 месяцев назад
Автор искренне делится опытом. Благодарю! Видно, что волнуется и мало опыта выступлений. А ещё много англицизмов и сленга. Беда не сколько в их наличии, а в том, что их много и они неуместны. Создаётся впечатление, что ими какие-то пробелы в аргументации или понимании закрываются.
@victorkochkarev2576
@victorkochkarev2576 8 месяцев назад
Данная профессия полна англицизмов и сленга, так что это более чем приемлимо. Особенно с учётом того, что исходная информация обычно на английском языке.
@rostislavteryaev3894
@rostislavteryaev3894 8 месяцев назад
че? Все нормально выступил и все фразы уместны
@vladislav_artyukhov
@vladislav_artyukhov День назад
Я бы на его месте больше бы на английском говорил 😂. Но он молодец, старался не делать каши языков
@user-fg3ed2gz7y
@user-fg3ed2gz7y 9 дней назад
Молодец, но почему бы просто не реализовать архитектуру как по книжке и не делать не пойми что, в итоге проблем не оберетесь, сделали бы все глобальное, зачем вам принцип инверсии ? в общем за опыт плюс, за все остальное минус
@newm_2002
@newm_2002 7 месяцев назад
сказал давайте попишем код ибо по презентации все ясно, а в коде нет в итоге сам создал через либу проект и ничего толком не показал
@vladislav_artyukhov
@vladislav_artyukhov День назад
30 минут
Далее
Became invisible for one day!  #funny #wednesday #memes
00:25
skibidi toilet multiverse 039 (part 1)
05:29
Просмотров 4,7 млн