Ща ссылку найду

По сути вся их IDE собрана из плагинов и каркаса. Та же поддержка Go, тоже обычный плагин... просто встроенный в GoLand, тупо удалить нельзя.

> просто встроенный в GoLand,
Ну да, можно на идею накатить и не париться впринципе

Кстати, а есть тут те, у кого обновление до go 1.14 поломало goland с включённым vendoring mode, перестали нормально видится зависимости
Поломался go list, не стартует из-за флагов

По факту чисто для красоты

Она слишком перегружена и огромна.)

Я бы из entity сущности распихал по соответствующим контекстам, а api унес бы в отдельный/отдельные пакеты. А то получается в одном пакете вместе лежат абстракции разных уровней. В  таком случае есть риск что кто-то например в сервис пробросит что-то из http к примеру...

Там есть Issue мое.

хаха

еще часы в стиме покажите

Это как распихал? Поподробнее плиз?

Ну, лишний раз подбивает съехать с vendor, тем более что корп проксю наконец-то подняли)

По началу у меня, вообще пакеты не стали автоматом загружаться, компиляция завершалась ошибкой загрузки пакета.

Я наоборот его просил в один пакет помещать, что бы легче было переносить и легче было переключаться, файлы сущности все рядом.

Например вынес бы в отдельный пакет api внутри пакета album. Чтобы не было физической возможности запихнуть что то из пакета api в album. Т.е. чтобы при такой попытке получалась circular dependency и ошибка компиляции. Ведь в сервисе там бизнес-логика. Она по хорошему не должна ни чего знать ни о каких http и других механизмах доставки. А в идеале даже не должна иметь возможность их вызвать. Но на самом деле это не так принципиально. Просто в текущей реализации есть вероятность вызвать какую то функцию из файла api.go в файле service.go. А такой вариант использования всю архитектуру сразу похоронит.

Мне кажется, это лишнее уже...) там сложно что-то не туда запихнуть в его структуре.

Ты чет путаешь) как можно сервисом что-то из api там вызвать, он же передаётся в api. Он не знает, что снаружи его... это же уровень uscase в Clear Architecture, он второй от центра.

Сложно, пока там нет практически бизнес-логики и мало другого кода. Т.е. пока это бойлерплейт. А потом один программист в файле api.go пишет какую то функцию или создаст структуру, а второй программист через 3 месяца эту функцию или структуру заюзает в service.go. И через пол года хрен распутаешь.