What architecture is this?

Hello, i always use this architecture but i don’t know if this has a name or if its ok to use like this.

image

It looks that you’re using the MVC approach in your Go projects (web-projects, I suppose).

In Go world, there are no bad/good/recommended project structures from the Go team, but there is a repository on Github that you can take a look at:

To be honest, you can explore Github and popular Go projects to understand the project structure better and choose one that suits your needs.

1 Like

yep, every company has your own guide, some thing like this, Uber Guide

https://github.com/uber-go/guide/blob/master/style.md

1 Like

golang-standards/project-layout is actually notoriously misleading and not an example of a “standard” project layout at all. See this issue created by rsc. Saying it’s “not an official standard” isn’t quite as accurate as saying it is actively discouraged by the Go team. That said, if you have a project layout that works for you and your team, use it.

The only things I try to adhere to are:

  • Keep it as simple as possible until it needs to be complex. I generally start out with just main.go in the root folder and re-evaluate as my project inevitably grows.
  • Putting thought into the package separation of duties fixes most unwieldy code problems.
  • If I have a monolith with multiple executables, adhere to each executable being in a subfolder of the /cmd folder. This seems to be pretty standard (at least in the circles I run in; your mileage may vary!).

Anyway, OP, your folder structure seems fine. Especially if it works for you. When I scan it, I can get a pretty good idea of what each package does. The only thing that I’m not 100% sure about is tmp, as that could be multiple things. But I’m sure a quick look at it would clear up any questions I had about it.

5 Likes