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” of doing something would be like (full of 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.
A complex system that works invariably evolved from a simple system that worked.
-- Gall's Law
For small applications, the project structure should be simple.
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.
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).
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.
Architectures that better separate “details” from what actually delivers value.
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.
Taking 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)
Quickly zooming in on the details. Here are simply the tools by which the domain will achieve its success.
I'm still a kid on the path that Golang offers, still figuring 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.
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
The above is the detailed content of GO — Project structure. For more information, please follow other related articles on the PHP Chinese website!