Małe projekty zazwyczaj nie potrzebują żadnej struktury. Wszystko, czego potrzebujesz, aby zacząć, to tylko main.go. Zalecam zawsze zaczynać projekt od pojedynczego pliku main.go.

Potem, gdy twój projekt się rozrasta (wyobraź sobie, że zdajesz sobie sprawę, że teraz musisz mieć dwie binarki), powszechnym podejściem jest dodanie folderu cmd/. Może to być dowolny dir, oczywiście, ale cmd jest czymś, co każdy gopher natychmiast rozpoznaje w projekcie.

Potem, gdy twoja baza kodu się rozrasta, zaczynasz dodawać więcej plików „.go” i więcej pakietów – każdy z nich będzie w osobnym podkatalogu (z definicji). I tu właśnie wielu początkujących staje się zdezorientowanych i przynosi wzorce strukturyzacji z innych języków lub frameworków.

W wielu innych językach, katalog jest używany do „umieszczania nazw” grup plików, jak handlers lub models, ale w Go, katalog jest oddzielnym pakietem (np. biblioteką). Więc „strukturyzacja katalogów” w Go tak naprawdę oznacza „jak abstrahować kod do podpakietów i kiedy”.

Ale generalnie, nie myślisz o strukturyzacji swojego repo, chyba że twoja baza kodowa o to prosi (tj. zbyt wiele plików, oczywiste abstrakcje, które mogą być ponownie wykorzystane i wyizolowane w swoim własnym pakiecie, itp).