I started programming using Golang for real this year (2022), and the thing I immediately did was look for references on what would be the best way to evolve my structure for the project. This post will be just one of many others that talk about the same subject, and, perhaps that's why I decided to write it.

Firstly, golang is already completely different in the way it deals with folders/packages, and, to improve, it has a very opinionated essence, with many official docs informing what the “goway” way of doing something would be (full of not me touch), however, in the way you organize your files and folders, there isn't really a direction, so everyone kind of gives their own interpretation of the world to this part.

I will divide this post into 3 references and then show how the mix of these references turned out in the project.

First reference

A complex system that works invariably evolved from a simple system that worked.
-- Gall's Law

For small applications, the project structure must be simple.

Second reference

The “community” did a survey of a set of historical and emerging design layout patterns common in the Go ecosystem. There are a lot of cool things in this survey, but what caught my attention were the /cmd and /internal folders.

/cmd

Main applications for this project.
The directory name for each application must match the name of the executable you want to have (e.g. /cmd/myapp).

/internal

Private application and library code. This is code that you don't want others to import into their applications or libraries. Note that this layout pattern is imposed by the Go compiler itself.

Third reference

Architectures that better separate the “details” from what really delivers value.

Result

For a simple application I try to keep it simple, however, when the scope gets a little larger, I try to make a slight differentiation between what is “core”/domain and what is detail/infrastructure.

Note that in cmd I don't have the tuttipet folder, as the reference project suggests. At first I tried to use the suggested pattern, but as this API already came out with a command line interface and a provider for terraform I decided to leave it this way.

Take a quick zoom in on the core. I try to be simplistic here and not create folders. I only maintain 1 point of contact with the external world (main.go), whatever is generalized has its own file and whatever is not remains within its context, simple.

With tuttipet.New (short, concise and evocative) the “dirty” layer can interact with the usecases (I find the word usecase easier to assimilate than interactor)

Take a quick zoom in on the details. Here are simply the tools by which the domain will achieve its success.

Conclusion

I'm still weak in the path that Golang offers, still trying to figure out what can be done with it, however, even though I don't like the Go way of doing some things, it has proven to be quite simple and robust.

Summary, trying to keep it simple when possible and if it gets too complex... I'll go back to the drawing board.

Other references

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-structure/
https://github.com/bnkamalesh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-structure-my-go-project/
https://blog.logrocket.com/flat-structure-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-structure-go-code/
https://dev.to/jinxankit/go-project-structure-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-structure/
https://go.dev/doc/effective_go#names
https://go.dev/blog/package-names

Original post: https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d