Scribd
Upload
12 views9 pages

How I structure my Golang projects

The document outlines a recommended project structure for building maintainable and scalable Go applications, combining community standards with principles from Clean Code. It details various folders such as cmd, internal, and app, each serving specific purposes like holding application code and handling incoming inputs. The author encourages viewing this structure as inspiration rather than a strict guideline, offering a link to a simple project for further exploration.

Uploaded by

vitea vitea
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views9 pages

How I structure my Golang projects

The document outlines a recommended project structure for building maintainable and scalable Go applications, combining community standards with principles from Clean Code. It details various folders such as cmd, internal, and app, each serving specific purposes like holding application code and handling incoming inputs. The author encourages viewing this structure as inspiration rather than a strict guideline, offering a link to a simple project for further exploration.

Uploaded by

vitea vitea
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

DANIELMESQUITTA.

COM

HOW TO STRUCTURE
YOUR BACKEND
FOR GOLANG
DEVS
BY DANIEL MESQUITA
01

Introduction
Building maintainable, scalable Go
applications often starts with a solid
project structure.

By pairing the community-driven golang-


standards/project-layout with the
guidance of Clean Code by Robert C.
Martin, you get a recipe for clarity,
testability, and growth.

DANIELMESQUITTA.COM
02

My project structure
cmd: contains the main.go
entry point for your
application
docs: API documentation
internal: holds the
application code (business
logic, handlers, etc.)
test: integration tests and
test configuration
tmp: temporary files (e.g.,
binaries generated by Air)

DANIELMESQUITTA.COM
03

The domain folder


entity: any relevant entity
(e.g., DB-stored or
application-specific)

errs: application known


errors (e.g., user not found)

usecase: Business logic like


CreateUser function

DANIELMESQUITTA.COM
04

The provider folder


Implements and defines
external interfaces (e.g.,
a payment gateway client),
allowing you to swap or
mock them in tests or in
different environments
easily when combined with
dependency injection.

DANIELMESQUITTA.COM
05

The pkg folder


It serves to centralize
auxiliary functions and
adapt external
dependencies to your
application’s specific
needs.

DANIELMESQUITTA.COM
06

The app folder


The app folder contains
the adapters that
handle incoming
inputs (e.g. HTTP
endpoints, gRPC
servers, CLI commands,
etc.) and translate them
into your domain’s use-
case invocations.

DANIELMESQUITTA.COM
07

Final words
This project structure reflects what I’ve
learned over time and what has worked
well for my teammates and me. Think of
it as inspiration, not the absolute truth.

If you’d like to explore a simple project


using this structure, I’ll leave a link in the
comments below.

DANIELMESQUITTA.COM
DONT FORGET TO
LIKE, SHARE AND
SAVE IF YOU LIKE
THIS POST
DANIEL MESQUITA

You might also like