Embora não haja uma obrigatoriedade em como organizar projetos Go, um recurso pouco explorado – pelo menos da maneira correta -, é a utilização da pasta internal .
A pasta internal é um recurso poderoso que permite organizar e encapsular código que não deve ser utilizado por outros packages. Em outras palavras, ela é perfeita para armazenar funções auxiliares, estruturas de dados, domínio e outros detalhes de implementação.
Como funciona
De forma simples, quando o compilador Go encontra uma pasta internal, ele a trata como um package separado e não exporta nenhum dos seus símbolos para fora do package ao qual ela pertence. Isso significa que qualquer código na pasta internal só pode ser acessado por outros arquivos dentro do mesmo package “principal”.
Em outras palavras, somente os arquivos e outros packages que tenham o mesmo diretório “PAI” que a pasta internal é poderem acessar o que estiver nela.
Para o conceito ficar mais claro, abaixo mostro dois exemplos de utilização, sendo o primeiro como proteger acesso de outros projetos e depois como proteger acesso de dentro do mesmo projeto.
Proteção contra acesso externo
A forma mais simples e também mais utilizada desse recurso é adicionar a pasta internal ao diretório raiz do projeto.
**. (ROOT)** ├── api ├── cmd ├── handlers **├── internal** ├── services ├── pkg ├── go.mod └── go.sum
Dessa forma, qualquer arquivo ou package dentro do mesmo projeto poderá acessar tudo que está na pasta internal, ou seja, deixar a pasta internal na raiz do projeto só protege o código de projetos externos.
Proteção contra acesso no mesmo projeto
Para prover uma proteção dentro do mesmo projeto, a pasta internal deve ser movida para dentro do package onde ficará o código.
. (root) ├── api ├── cmd ├── handlers **├── categories │ ├── internal │ │ └── domain.go │ └── category.go** **├── products │ ├── internal │ │ └── domain.go │ └── product.go** ├── services ├── pkg ├── go.mod └── go.sum
No exemplo acima, tudo o que estiver na pasta categories/internal ou em suas subpastas, só será acessível pelos arquivos no package categories e seus “subpackages”, por exemplo, categories/repositories.
Ao organizar o projeto dessa forma, o próprio compilador do Go irá garantir que os packages products, api, cmd, handlers, services e pkg, não consigam acessar o que estiver dentro de categories/internal. (o mesmo acontece para products/internal).
Conclusão
A pasta internal é um recurso poderoso que pode ajudar a manter um código mais limpo, organizado e encapsulado em um package.
Em projetos que implementam Domain-Driven Design, a utilização da pasta internal é, sem sombra de dúvidas, um ótimo recurso para encapsular o domínio.
Por último, se você quer aprender mais sobre estrutura de projeto, Domain-Driven Design, postgres e gRPC, confira a Imersão Backend Go. São mais de 200 aulas, além de acesso a um grupo de estudos no Discord.
Até a próxima!
Faça parte da comunidade!
Receba os melhores conteúdos sobre Go, Kubernetes, arquitetura de software, Cloud e esteja sempre atualizado com as tendências e práticas do mercado.
Livros Recomendados
Abaixo listei alguns dos melhores livros que já li sobre GO.





Achei bem interessante. Me parece ser um recurso bem poderoso, mas me pergunto porque a comunidade resolveu não adotar muito essa estrutura. Vejo bastante essa abordagem https://github.com/golang-standards/project-layout
Acredito que por dois motivos.
1. Falta de conhecimento do real funcionamento da linguagem e como ela trata diferente o conteúdo dessa pasta.
2. Por ser completamente livre de obrigatoriedades na forma de se estruturar um projeto, muitas pessoas que vem de outra linguagem acabam utilizando o padrão desse repo sem se questionar muito os motivos dessa organização.