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

Рет қаралды 13,248

Күн бұрын

Подписывайтесь на наш канал здесь и в телеграмм 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-приложении.

Пікірлер: 41

@nikitajolobov4591 3 ай бұрын

большое спасибо за доклад, все кратко по дело. Отдельное спасибо за пакет goro

@aleksandrpetrov3938 Ай бұрын

13:50 - если в "слое сервисов есть несколько пакетов, и они могут вызывать друг друга", получится циклический импорт же :(

@Elteruin 9 ай бұрын

Крутой доклад.

@dmitriyosin8528 Жыл бұрын

Спасибо за видео!

@EvroneDevelopment Жыл бұрын

Рады стараться!

@user-bh8xz4xy7o 8 ай бұрын

Гений!!!

@waffleboot 8 ай бұрын

Хороший доклад, мы к такому же пришли, ну точнее чел с опытом в DDD нас направил на путь истинный. Единственно не стали сильно глобалить entity чтоб аж json в них прописывать. И usecase у нас может работать с репо. Зачем писать service для get-ручки? Handler вызывает facade, facade вызывает usecase или facade может сам в репо сходить. Хотя это вопрос конечно как логику приложения делить между usecase и service. Ну и не пишем в каждом сервисе interface для репо из одного метода. Репо-интерфейсы вынесены в порты (архитектура порты & адаптер) и каждый сервис импортит порт. А если нужен все таки интерфейс для сервиса, то у нас он exported, а не внутренний для пакета. Когда интерфейс с lower case именем понятно что он под внутренние цели. Но у нас они в upper case как признак того что это внешняя зависимость.

@mnogokotin 10 ай бұрын

спасибо за видео

@EvroneDevelopment 9 ай бұрын

Рады что вам понравилось!

@ntldrzic 3 ай бұрын

спасибо за свой опыт. Можно ли указать какой-либо публичный репозиторий, чтобы посмотреть это в коде?

@user-em2jh9pi3i 3 ай бұрын

Спасибо за классный доклад. Можно где-то презентацию скачать?

@user-fh6xg9pn3y 9 ай бұрын

Начал за здравие, кончил - за упокой) Про глобальные entity. С одной стороны верно, т.к. главное правило зависимостей соблюдается. Т.е. есть центральные бизнес-сущности (entity), которые не зависят ни от чего. А репозитории и контроллеры - зависят от них. Зря не любишь круглую диаграмму. Если на ней нарисовать стрелки зависимостей, то увидишь, что все стрелки идут в центр. Т.е. переферия зависит от бизнес-ядра. DTO для того и нужно, чтобы укоротить стрелки, чтобы разорвать зависимость между ядром и контроллером. Вот ты у entity переименовал поле или удалил. И сигнатура АПИ тут же ломается. Между ними как раз должен быть промежуточный DTO, который на себя возьмёт роль поддержания совместимости. Вот там нормально выглядят json теги.

@EvroneDevelopment 9 ай бұрын

Не стоит быть столько критичным ;)

@user-fh6xg9pn3y 9 ай бұрын

@@EvroneDevelopment Не стоит быть таким душнилой, Вы хотели сказать наверное 😂

@akhmetgareev 6 ай бұрын

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

@redneck_prm5429 Жыл бұрын

А ведь каких-то лет пять назад гошники при упоминании чистой архитектуры начинали шипеть что-то вроде "валите обратно в свою жабу". Глобальные entity дабы не делать dto - может и имеет право на жизнь. Но всё-таки идея перекидывать между слоями определенные data structure несет не только изоляцию слоев, но и возможность эти самые ds кастомизировать под необходимости конкретных слоёв. entity всёж по определению предельно чисты и не содержат ничего от следующих слоёв.

@TheDavBag 11 ай бұрын

есть N слоёв и M сущностей с мапингом при каждом переходе из слоя в слой. Много ли будет накладной и, скорее всего, бесполезной работы?

@redneck_prm5429 11 ай бұрын

@@TheDavBag Идеологи чистой архитектуры открыто пишут, что она стоит заметных дополнительных затрат и бездумно совать ее куда попало не стоит.

@TheDavBag 11 ай бұрын

@@redneck_prm5429 да, и насколько мне известно, ЧА создавалась для решения задач модульного монолита

@den_is_kuts8139 Күн бұрын

На все слои без необходимости не нужно конечно делать, иначе оверинженеринг, но хотя бы с инфрой разделить стоит

@evgeniybudaev1690 6 ай бұрын

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

@gooseman5578 6 ай бұрын

а чего без github-а то? :(

@rostislavteryaev3894 8 ай бұрын

Но хэндлер это же тоже адаптер)

@TheDavBag 11 ай бұрын

paymenter userer subscripter =) думаю, можно обойтись без usecase, а может даже без service также, я бы не советовал писать сущности с экспортируемыми полями - это ломает инкапсуляцию поведения

@user-ps6bb1fm9u 10 ай бұрын

Ломает да, только в Go от этого никуда не денешься, т.к. не сможем анмаршалить/маршалить структуры из/в json/db/... По этому как было сказано в видео можно городить всякие мапперы,гидраторы и прочие преобразователи.

@TheDavBag 10 ай бұрын

@@user-ps6bb1fm9u не ломает, надо просто имплементировать Unmarshaller

@alex-0x6b 9 ай бұрын

Называя папку usecase вы жестко привязываетесь к дядюшке Бобу, а оно вам надо?) Считаю это определение максимально неудачным.

@EvroneDevelopment 9 ай бұрын

У каждого свой путь ;)

@user-fh6xg9pn3y 9 ай бұрын

Нормальное название) Зато понятно о чём речь!

@alex-0x6b 9 ай бұрын

Я решил добавить чучуть больше аргументов против использования термина usecase (случай использования или пользовательский случай). Боб просто обобщил бизнес-логику назвав это usecase, но такое определение в коде делает его сильно шаблонным. Не знаю, может у меня просто такое отношение, ведь мне кажется логичнее назвать это, ну скажем, хотябы domain. Простите за занудство, ведь мы все прекрасно знаем, что на названия программист тратит 90% времени. 😀

@user-fh6xg9pn3y 9 ай бұрын

@@alex-0x6b Есть чёткое ощущение, что Вы неверно понимаете Чистую Архитектуру и понятие "usecase" в частности. По-русски это будет "Вариант использования", а по смыслу "Бизнес-правила, связанные в конкретным приложением". "domain" - это неверное название (неконкретное). Пример: у вас служба записи к врачу. 1. Критические бизнес-правила (самое ядро, сущности, entity) - это про врачей, пациентов, болезни и график работы. Т.е. то, что существует без всяких приложений. Эти сущности из реального мира, они существовали еще когда не было никакого интернета. 2. usecase - Это то, что связано с конкретным приложением. Например, процедура регистрации на сайте через веб, отображение информации о враче на одной карточке вместе с фоткой. Это то, что вроде как рядом с "доменом", но чётко завязано на конкретное веб-приложение. Мобильное приложение для записи к врачу - это второй usecase, у него и процедуры регистрации другие, и протоколы и форматы данных и т.д. "Доменом" обычно называют эти две области вместе. Либо критические бизнес-правила плюс небольшая часть из usecase.

@Aaaa-jn4bm 7 ай бұрын

Usecase - это буквально переводится как бизнес-сценарии, самое подходящее название. Ниже вы предложили domain.. domain - это буквально предметная область, название не передаёт прямой сути (как и "сервисы")

@user-zg8ij3kt1h 9 ай бұрын

Автор искренне делится опытом. Благодарю! Видно, что волнуется и мало опыта выступлений. А ещё много англицизмов и сленга. Беда не сколько в их наличии, а в том, что их много и они неуместны. Создаётся впечатление, что ими какие-то пробелы в аргументации или понимании закрываются.

@victorkochkarev2576 8 ай бұрын

Данная профессия полна англицизмов и сленга, так что это более чем приемлимо. Особенно с учётом того, что исходная информация обычно на английском языке.

@rostislavteryaev3894 8 ай бұрын

че? Все нормально выступил и все фразы уместны

@vladislav_artyukhov 4 күн бұрын

Я бы на его месте больше бы на английском говорил 😂. Но он молодец, старался не делать каши языков

@newm_2002 7 ай бұрын

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

@vladislav_artyukhov 4 күн бұрын

30 минут

@user-fg3ed2gz7y 12 күн бұрын

Молодец, но почему бы просто не реализовать архитектуру как по книжке и не делать не пойми что, в итоге проблем не оберетесь, сделали бы все глобальное, зачем вам принцип инверсии ? в общем за опыт плюс, за все остальное минус