Привет друзья! У меня есть теоретический вопрос по названию и

функциональному назначению пакетов в GO.
В языках, где есть неймспейсы видна иерархия классов. То есть имея какой-то, например, обработчик запросов у нас будут какие-то другие пакеты с классами типа:
Handler\Model\SomeResponse.class
Handler\Factory.class
Handler\Middleware\SomeMiddleware.class
и тд.

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

Вопрос, как в го бы выглядела подобная структура?

это выглядело бы как:
hander.SomeResponse
handler.Factory
handler.SomeMiddleware

или нужно создавать отдельные под пакеты типа
handlermiddleware.SomeMiddleware
handler.Factory
и тд

Боюсь, что нет однозначного ответа на ваш вопрос. Golang не диктует вам, какую структруру проектов использовать. Вы должны сами определить целесообразность того или иного подхода в каждом конкретном случае. К примеру, для реализации простых модулей/проектов вполне подойдёт плоская структрура с hander.SomeResponse handler.Factory handler.SomeMiddleware, но как только начинаются проблемы с неймингами, стоит подумать об использовании отдельных директорий для ваших абстракций/реализаций a la response.SomeResponse factory.SomeFactory middleware.SomeMiddleware.

А есть какой-то манифест или может книга или какой-либо другой ресурс на котором прописано, что вообще должен нести в себе пакет в Go? Мне просто сложно понять как правильно определять функционал в пакеты или на каком моменте стоит разносить пакет над под пакеты.

Здравый смысл и опыт, сын ошибок трудных, вам в помощь)

https://blog.golang.org/organizing-go-code

тема намеренно оставлена для холиваров между коллегами) в internal все клади! нет, давайте по пакетам разложим, и т д

Интересный доклад на эту тему от Kat Zien https://www.youtube.com/watch?v=oL6JBUk6tj0

Эта статья тоже не даёт однозначного ответа на заданный вопрос. It is easy to just throw everything into a "grab bag" package, but this dilutes the meaning of the package name (as it must encompass a lot of functionality) and forces the users of small parts of the package to compile and link a lot of unrelated code. On the other hand, it is also easy to go overboard in splitting your code into small packages, in which case you will likely becomes bogged down in interface design, rather than just getting the job done.