Kleine projecten hebben meestal geen structuur nodig. Alles wat je nodig hebt om te beginnen is gewoon main.go. Ik raad aan om een project altijd te beginnen met slechts één main.go bestand.

Toen uw project groeit (stel, u realiseert zich dat u nu twee binaries moet hebben), is de gebruikelijke aanpak om cmd/ map toe te voegen. Dat kan elke directory zijn, natuurlijk, maar cmd is iets dat elke gopher onmiddellijk herkent in het project.

Toen, als je codebase groeit, begin je meer “.go” bestanden en meer pakketten toe te voegen – elk van hen zal in een aparte subdirectory staan (per definitie). En hier raken veel nieuwkomers in de war en nemen structureringspatronen uit andere talen of frameworks mee.

In veel andere talen wordt de directory gebruikt voor “namespacing” van een aantal bestanden, zoals handlers of models, maar in Go is de directory een apart pakket (d.w.z. een bibliotheek). Dus “mappen structureren” betekent in Go eigenlijk “hoe abstraheer je code in subpackages en wanneer”.

Maar over het algemeen denk je niet na over het structureren van je repo, tenzij je codebase erom vraagt (d.w.z. te veel bestanden, voor de hand liggende abstracties die kunnen worden hergebruikt en geïsoleerd in een eigen pakket, etc).