When it comes to structuring Go projects, a few popular approaches have emerged over the years, particularly influenced by Go’s preference for simplicity and clarity. Here are the most common ones:
1. Standard Go Project Layout (golang-standards/project-layout)
- This layout is often seen as the "default" structure for many Go projects. It follows conventional folder names and keeps the code organized into commonly understood directories.
- Pros: Well-documented and widely used, making it easy to understand for new developers joining the project.
- Cons: Can feel a bit heavy for smaller projects due to the number of directories, some of which may be unnecessary at the start.
/cmd # Main applications of the project
/pkg # Library code that's OK to use by other applications
/internal # Private application and library code
/api # API definitions, like gRPC or OpenAPI specs
/web # Web assets
/configs # Configuration files
/scripts # Various scripts for building or other automation
/build # Packaging and continuous integration
/docs # Documentation2. Domain-Driven Design (DDD)
- Inspired by Domain-Driven Design, this structure organizes code by domain or feature, which helps keep related files and logic together.
- Pros: Keeps features self-contained, which improves code readability and maintainability. Good for larger, more complex projects.
- Cons: Takes time to learn and implement correctly; may not be necessary for simpler projects.
/app
├── /user # User domain logic
├── /order # Order domain logic
├── /product # Product domain logic
└── /shared # Shared utilities and interfaces3. MVC Pattern
- The Model-View-Controller (MVC) pattern is less common in Go because Go applications typically aren't web frameworks. However, it's still sometimes used in projects where it makes sense to separate business logic, data, and user interface.
- Pros: A familiar structure for developers coming from other languages with MVC frameworks.
- Cons: Can be less idiomatic in Go, as Go generally encourages a simpler, function-oriented structure rather than strict patterns.
/controllers # Handle HTTP requests and call services
/models # Data structures, database interaction
/views # Templates and other output-related code
/services # Business logic4. Hexagonal Architecture (Ports and Adapters)
- Also called the "Clean Architecture," this style separates application code into core (business logic), interfaces (ports), and adapters.
- Pros: Highly testable and modular, ideal for long-term maintenance, scalable and flexible.
- Cons: Can feel overly complex for smaller projects.
/core # Business logic
└── /domain # Domain entities
/interfaces # Interface definitions (e.g., repository, service)
/adapters # Adapters for different storage, APIs, etc.5. Simple Flat Structure (Go idiomatic)
- Some Go developers prefer keeping it simple, especially for small projects, by avoiding deep nesting and complex directories. Files are placed in the root or only minimal folders like /pkg and /cmd.
- Pros: Simple and fast to set up, minimal structure allows for quick prototyping.
- Cons: Not ideal for larger projects, can get disorganized as the codebase grows.
/cmd # Main application entry points
/pkg # Reusable packages (if any)Most Popular Choice: Standard Project Layout
For most developers and companies, the Standard Go Project Layout is the most popular due to its familiarity and community support. It provides a clean, organized structure while still allowing flexibility as the project grows. The layout is mature, open-ended enough for scalability, and has a lot of examples across the Go ecosystem, making it easier for teams to adopt without much customization.
Related Articles
•
•
•