Не сможет, уровни не пересекаются в ту сторону.

Ну как как, 2 файла в одном пакете (неймспейсе), можно вызывать что угодно из чего угодно. )) То что Сlean этого не предполагает, не означает, что не придет джун или может миддл который не особо знает что там можно а что нельзя и не сделает этого. 🙂

Как можно передавать в параметры структурку?

Там нет функций кроме NewService, NewRepository и т.д., все остальное методы структуры. Или ты про Validate?

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

https://github.com/qiangxue/go-rest-api/issues/2 мы это обсуждали уже.

Ну там можно долго спорить и обсуждать, я бы предложил не статью все таки читать, а прочесть Вернона и Эванса. Оно на практике так не работает (в больших проектах), что есть пакет с сущностями entity и мы все их оттуда тянем. Этих user в проекте может быть 10-ки. и называться они в каждом пакете могут по разному. user, author, customer и т.п. Проще говоря "Создание глобальной модели" для всего приложения - это самая распространенная ошибка в этих делах. А тут в бойлер плейте бизнес модель как бы одна. внутри entity. При этом еще и анемичная (Хотя не суть, на таком мелком примере вообще сложно все это показать нормально).

Жалко он предыдущее репо полностью убил... там больше обсуждений было, на пару лет.

Пока по мне, это лучшее, что я видел на гитхабе из стартеров. Все лаконично и все понятно. Перевели все свои актуальные проекты на этот бойлерплейт. Доделал только токены, ввёл RefreshToken и ставлю куки специальные.

Никому не понятен вопрос, сформулируйте корректно.

Я свои entities разложил по папкам entity в user, album и т.д.

Я и не говорю что он плохой, выглядит вполне достойно, и для большинства проектов наверное подойдет. Проблемы всегда начинаются при интеграции контекстов. Когда их несколько и бизнес-логика в них несовместима друг с другом.

Это как, например?

Может тогда их нужно в отдельные проекты распихать вообще?
Наделать микросервисов...

Ну к прмеру у пользователя есть посты, у поста есть комментарии у комментария есть авторы (читай пользователи), у них есть посты и так далее... Часто пытаются городить одну модель.

Я думаю и это можно разрулить) не страшно...)))

Ладно, че то мы заофтопились, давайте завершим, или в личку пойдем ))

Короче, я доволен, что мы такой стартер смогли создать. До этого он был ужасный... не совсем конечно, но разбить на микросервисы было проблематично и все по разным папкам по слоям. (

Ок. Можем и в личке, тема интересная. А народу полезно, что уже успели обсудить, пусть поинтересуются проектом. Звездочек наставят. Предыдущий его стартер под 1000 ☆ имел, если не больше. Жалко, что он его удалил.

Вот предположим я хочу album унести в отдельный микросервис, чего там не хватает? В пакете? И что там лишнее? На мой азгляд api.go лишний (в другом микросерисе могут быть другого типа обработчики/или вообще grpc какой-нить, зачем мне эндпоинты из этого пакета?) а еще сущности не хватает. Сервис есть, а сущность надо копировать из другого пакета (entity). Т.е. в идеале хотелось бы просто заимпортить папку album и привет, вся бизнес-логика приехала.

Это в идеале, но увы... ничего идеального не бывает, палка всегда о двух концах.) Тогда придется бегать по папкам. А я ленивый.