golang-project-layout

Use a right-sized Go project layout that matches real architectural needs. This prevents over-structuring early by applying idiomatic conventions like `cmd/` for wiring and `internal/` for private packages, keeping the codebase maintainable.

Decide between `internal/` vs `pkg/` by limiting `internal/` to private application code and reserving `pkg/` for reusable public libraries. This ensures correct Go conventions and practical engineering decisions for your codebase boundaries.

Your Go monorepo needs `go.work` for optional multi-module workspaces. It enables local development across modules without modifying module naming rules or `go.mod` dependencies, ensuring correct workspace usage.

Set up a Go CLI tool by keeping `cmd/` focused only on wiring and placing business logic in `internal/`. Apply correct module and package naming conventions, like lowercase singular names, to maintain an idiomatic directory layout.

You can apply 12-Factor app rules when structuring Go services. The layout guidance ensures services follow configuration and statelessness principles while co-locating tests with code for practical engineering decisions.

To establish a team-ready Go project, you need a Makefile, .gitignore, and golangci-lint configuration. These root files support practical engineering decisions and standardize testing layout and workspace guidance.