golang-project-layoutlisted

# Go Project Layout Let dependency direction and ownership shape directories. Go does not require a single repository layout. ## Inspect before proposing structure Read go.mod, go.work, executable entry points, public imports, generated-code configuration, build and deployment files, tests, and repository instructions. Identify: - one module or multiple independently versioned modules; - libraries versus executable targets; - public packages consumed outside the module; - code that must be hidden from external importers; - shared domain concepts versus incidental reuse; - generated, embedded, migration, fixture, and deployment artifacts; - compatibility constraints on import paths. Do not restructure a working repository for visual symmetry. Moving a Go package changes its import path and can be a breaking API change. ## Choose boundaries Prefer a shallow structure until real ownership or dependency boundaries justify more depth. - Keep one main package per executable target. A cmd directory is useful for multiple commands or when it matches repository convention, but is not mandatory for a single small program. - Use internal when the compiler-enforced import boundary is valuable. Do not put everything under internal by habit. - Public reusable packages should have a coherent API and domain name. A top-level pkg directory is optional and should not be introduced as ceremony. - Avoid generic common, shared, helpers, or utils packages. Place behavior with the domain th