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

[@nikitajolobov4591]

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

[@ntldrzic]

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

[@АртемГалкин-ж6з]

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

[@КириллПопов-л1ж]

Мне очень понравилось, но так и не понял зачем вводить дополнительный слой usecase. Почему сам service не может определять usecase?

[@GeekanskiY]

Сам когда-то не понимал этой логики, но нашёл удобным по следующей причине: Service - валидация, сериализация, первичная обработка данных короче, ну и формирование ответа Use case - непосредственно бизнес логика В достаточно больших приложениях, вернее даже в приложениях с большими моделями для запросов/ответов - удобно. В маленьких - это не нужно

[@ibraim3197]

@@GeekanskiY ты неправильно понял, тк сервис не должен заниматься формированием ответа, это прерогатива слоя хендлеров

[@redneck_prm5429]

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

[@TheDavBag]

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

[@redneck_prm5429]

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

[@TheDavBag]

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

[@den_is_kuts8139]

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

[@waffleboot]

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

[@ПавелБачурин-д3к]

А как между всеми этими слоями должны прокидываться ошибки, если эти слои независимые?

[@dmitriyosin8528]

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

[@EvroneDevelopment]

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

[@СергейРодин-ю3ъ]

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

[@EvroneDevelopment]

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

[@СергейРодин-ю3ъ]

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

[@akhmetgareev]

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

[@evgeniybudaev1690]

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

[@Elteruin]

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

[@aleksandrpetrov3938]

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

[@deniss5034]

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

[@gooseman5578]

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

[@mnogokotin]

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

[@EvroneDevelopment]

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

[@rostislavteryaev3894]

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

[@alex-0x6b]

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

[@EvroneDevelopment]

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

[@СергейРодин-ю3ъ]

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

[@alex-0x6b]

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

[@СергейРодин-ю3ъ]

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

[@Aaaa-jn4bm]

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

[@TheDavBag]

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

[@ДенисДавыдов-ц6х]

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

[@TheDavBag]

@@ДенисДавыдов-ц6х не ломает, надо просто имплементировать Unmarshaller

[@ВладимирАкимов-х5х]

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

[@Programscape]

Гений!!!

[@developmentapp]

На хер тогда вышел, раз не успеешь!😄

[@newm_2002]

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

[@vladislav_artyukhov]

30 минут

[@ТимофейЁлкин-о9е]

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

[@victorkochkarev2576]

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

[@rostislavteryaev3894]

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

[@vladislav_artyukhov]

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