Архитектура Go проекта на практике
HTML-код
- Опубликовано: 2 июн 2024
- Подписывайтесь на наш канал здесь и в телеграмм 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-приложении. 
Наука
![DRAGON BALL: Sparking! ZERO - Fused Warriors Trailer [BUDOKAI TENKAICHI Series]](http://i.ytimg.com/vi/84p4Lvyfyes/mqdefault.jpg)
большое спасибо за доклад, все кратко по дело. Отдельное спасибо за пакет goro
спасибо за свой опыт. Можно ли указать какой-либо публичный репозиторий, чтобы посмотреть это в коде?
Спасибо за классный доклад. Можно где-то презентацию скачать?
Спасибо за видео!
Рады стараться!
13:50 - если в "слое сервисов есть несколько пакетов, и они могут вызывать друг друга", получится циклический импорт же :(
Хороший доклад, мы к такому же пришли, ну точнее чел с опытом в DDD нас направил на путь истинный. Единственно не стали сильно глобалить entity чтоб аж json в них прописывать. И usecase у нас может работать с репо. Зачем писать service для get-ручки? Handler вызывает facade, facade вызывает usecase или facade может сам в репо сходить. Хотя это вопрос конечно как логику приложения делить между usecase и service. Ну и не пишем в каждом сервисе interface для репо из одного метода. Репо-интерфейсы вынесены в порты (архитектура порты & адаптер) и каждый сервис импортит порт. А если нужен все таки интерфейс для сервиса, то у нас он exported, а не внутренний для пакета. Когда интерфейс с lower case именем понятно что он под внутренние цели. Но у нас они в upper case как признак того что это внешняя зависимость.
Доклад вроде бы хороший, но мне как новичку без наглядного работающего кода не понять что и как между собой взаимодействует
Крутой доклад.
спасибо за видео
Рады что вам понравилось!
Гений!!!
А ведь каких-то лет пять назад гошники при упоминании чистой архитектуры начинали шипеть что-то вроде "валите обратно в свою жабу".
Глобальные entity дабы не делать dto - может и имеет право на жизнь. Но всё-таки идея перекидывать между слоями определенные data structure несет не только изоляцию слоев, но и возможность эти самые ds кастомизировать под необходимости конкретных слоёв. entity всёж по определению предельно чисты и не содержат ничего от следующих слоёв.
есть N слоёв и M сущностей с мапингом при каждом переходе из слоя в слой. Много ли будет накладной и, скорее всего, бесполезной работы?
@@TheDavBag Идеологи чистой архитектуры открыто пишут, что она стоит заметных дополнительных затрат и бездумно совать ее куда попало не стоит.
@@redneck_prm5429 да, и насколько мне известно, ЧА создавалась для решения задач модульного монолита
а чего без github-а то? :(
Начал за здравие, кончил - за упокой) Про глобальные entity.
С одной стороны верно, т.к. главное правило зависимостей соблюдается. Т.е. есть центральные бизнес-сущности (entity), которые не зависят ни от чего. А репозитории и контроллеры - зависят от них.
Зря не любишь круглую диаграмму. Если на ней нарисовать стрелки зависимостей, то увидишь, что все стрелки идут в центр. Т.е. переферия зависит от бизнес-ядра.
DTO для того и нужно, чтобы укоротить стрелки, чтобы разорвать зависимость между ядром и контроллером. Вот ты у entity переименовал поле или удалил. И сигнатура АПИ тут же ломается.
Между ними как раз должен быть промежуточный DTO, который на себя возьмёт роль поддержания совместимости. Вот там нормально выглядят json теги.
Не стоит быть столько критичным ;)
@@EvroneDevelopment Не стоит быть таким душнилой, Вы хотели сказать наверное 😂
это еще добавит слой мапперов из дто в ентити и обратно + тесты. зависит от размера проекта конечно, но если это сервис ближе к микро, чем к макро, то имхо подход Тиграна сильно упрощает. Особенно учитывая что там и так достаточно много бойлерплейта, особенно на этапе инициализации. В авито плюс-минус к тому же пришли в итоге. Удобно, особенно покрывать тестами каждый слой независимо
Но хэндлер это же тоже адаптер)
paymenter userer subscripter =)
думаю, можно обойтись без usecase, а может даже без service
также, я бы не советовал писать сущности с экспортируемыми полями - это ломает инкапсуляцию поведения
Ломает да, только в Go от этого никуда не денешься, т.к. не сможем анмаршалить/маршалить структуры из/в json/db/...
По этому как было сказано в видео можно городить всякие мапперы,гидраторы и прочие преобразователи.
@@user-ps6bb1fm9u не ломает, надо просто имплементировать Unmarshaller
Называя папку usecase вы жестко привязываетесь к дядюшке Бобу, а оно вам надо?) Считаю это определение максимально неудачным.
У каждого свой путь ;)
Нормальное название) Зато понятно о чём речь!
Я решил добавить чучуть больше аргументов против использования термина usecase (случай использования или пользовательский случай).
Боб просто обобщил бизнес-логику назвав это usecase, но такое определение в коде делает его сильно шаблонным. Не знаю, может у меня просто такое отношение, ведь мне кажется логичнее назвать это, ну скажем, хотябы domain.
Простите за занудство, ведь мы все прекрасно знаем, что на названия программист тратит 90% времени. 😀
@@alex-0x6b Есть чёткое ощущение, что Вы неверно понимаете Чистую Архитектуру и понятие "usecase" в частности. По-русски это будет "Вариант использования", а по смыслу "Бизнес-правила, связанные в конкретным приложением". "domain" - это неверное название (неконкретное).
Пример: у вас служба записи к врачу.
1. Критические бизнес-правила (самое ядро, сущности, entity) - это про врачей, пациентов, болезни и график работы. Т.е. то, что существует без всяких приложений. Эти сущности из реального мира, они существовали еще когда не было никакого интернета.
2. usecase - Это то, что связано с конкретным приложением. Например, процедура регистрации на сайте через веб, отображение информации о враче на одной карточке вместе с фоткой. Это то, что вроде как рядом с "доменом", но чётко завязано на конкретное веб-приложение.
Мобильное приложение для записи к врачу - это второй usecase, у него и процедуры регистрации другие, и протоколы и форматы данных и т.д.
"Доменом" обычно называют эти две области вместе. Либо критические бизнес-правила плюс небольшая часть из usecase.
Usecase - это буквально переводится как бизнес-сценарии, самое подходящее название.
Ниже вы предложили domain.. domain - это буквально предметная область, название не передаёт прямой сути (как и "сервисы")
Автор искренне делится опытом. Благодарю! Видно, что волнуется и мало опыта выступлений. А ещё много англицизмов и сленга. Беда не сколько в их наличии, а в том, что их много и они неуместны. Создаётся впечатление, что ими какие-то пробелы в аргументации или понимании закрываются.
Данная профессия полна англицизмов и сленга, так что это более чем приемлимо. Особенно с учётом того, что исходная информация обычно на английском языке.
че? Все нормально выступил и все фразы уместны
сказал давайте попишем код ибо по презентации все ясно, а в коде нет
в итоге сам создал через либу проект и ничего толком не показал