The overall approach to folder structure can be a personal thing, and doesn't matter too much what you settle on. My own preference is for something like:

  github.com/<user>/<repo>
  |- main.go
  |  |- config/
  |  |- db/
  |  |- server/
  |  |- router/
  |  |- handler/
  |  |  |- get/
  |  |  |- put/
  etc.

In this setup, the router sub-package might import handler/get, handler/put, and so on, returning a router, which can typically be passed as an http.ServeMux to a Start or Run func in the server sub-package. main() winds up doing the bulk of any initialization sub-packages need, but not much else.

At various points you'll probably find that sub-packages become general enough that they can be easily broken out into their own repos and maintained separately. This can wind up being a good goal to shoot for when designing the APIs for each sub-package.

But wouldn't be better to organize it in domains, together with clean architecture? Because if the application have too many domains, it can get a bit messy, doesn't it? (Although if a micro-service strategy is used this shouldn't be a problem)

If your application requires multiple servers running multiple domains, you're probably better off with a microservice architecture.

Is this something that others are interested in as well?

Btw what kind of info would you like to see in a write up about this?

I am always interested in how to organize the folder architecture in a way that, in the future, it will not get in front of the development team.

Example: MVC was one of the go-to choices some years ago with folders /models, /view and /controllers, where everything was put in it. But, nowadays we know that it can get messy, specially when there are too many domains. Besides that, MVC isn't appropriated for the REST world (the V is not suited for that).