An opinionated guideline for structuring and developing Go web applications/services following DDD and Clean Architecture principles.
Goapp is a comprehensive guideline for structuring Go web applications and services, designed to promote maintainability and scalability. It provides a clear directory layout and architectural patterns based on Domain-Driven Design and Clean Architecture, helping developers build robust applications with proper separation of concerns.
Go developers building web applications or services who need a standardized, maintainable project structure, particularly those working on projects that may scale or require clear separation between business logic and external frameworks.
Developers choose Goapp for its opinionated, battle-tested structure that enforces best practices like dependency inversion and domain-driven organization, reducing architectural decisions and promoting consistency across Go projects.
An opinionated guideline to structure & develop a Go web application/service
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides a standardized directory layout with internal, cmd, pkg, and domain packages, making it easy to navigate and maintain large codebases, as detailed in the README's breakdown.
Organizes code around business domains like users and usernotes, facilitating better management of complex logic and team collaboration, based on years of experience noted in the philosophy.
Implements Clean Architecture to keep core business logic separate from external frameworks, allowing flexibility in tool choices, as emphasized in the dependency flow diagram.
Centralized API package ensures uniform behavior across multiple transport layers (HTTP, gRPC, Kafka), reducing inconsistencies and bugs, as explained in the internal/api section.
Recommends unit testing pure functions in domain packages and integration tests with real dependencies, aiding in robust testing strategies, with examples in internal/users_test.
The elaborate directory structure with multiple layers (e.g., configs, api, domain packages) requires significant configuration and understanding, which can be daunting for new projects or developers.
Enforces Domain-Driven Design and Clean Architecture, which might not suit projects with simpler needs or teams accustomed to different patterns like MVC, limiting flexibility.
Recommends using custom packages for errors and logging (e.g., naughtygopher/errors), adding external dependencies that need to be maintained and integrated, increasing project complexity.
As a guideline rather than a framework, it lacks built-in tools for common tasks like routing or ORM, requiring developers to choose and integrate their own solutions, which can lead to fragmentation.