Project organization is one of the most common mistake made by Go Developer. Go provides a lots of freedom for designing the packages and modules hence it is not easy task to organize the project. is The purpose of organizing the project are maintainability, readability, consistency and so on.
Because if go is going to be a language that companies invest in for the long term, the maintain of go program, the ease of which they can change, will be a key factor in their decision.
Dave Cheney, Golang UK 2016 Keynote
As a part of this blog, we mostly discussed on how we structuring the go project and few best practices and ways to improve how we organize the project.
Project structure
Structuring a project is one of the first steps toward starting any software project. In Golang, there are no specific convention for structuring the project.The purpose of structuring the project are make consistent, easy to understand and maintain, easy to change and loosely coupled and easy to test. While design the project structure make simple as possible, but no simpler. Software design reflects how the software works, similarly project structure reflects the design exactly.
Project structure depends on the size, use cases,workflow and requirement of project. There are different ways to structuring the project such as flat structure, layered architecture (group by function), group by module, domain driven development (DDD), group by context, hexagonal architecture and so on. However, one layout has emerged over the years ( i.e. https://github.com/golang-standards/project-layout ). Let’s discussed about this layout main directories briefly:
/cmd – The main source files. The main.go of monitor application should live in /cmd/monitor/main.go
/internal – Private code that we don’t want others importing for their applications or libraries.
/pkg – Public code that we want to expose to others.
/test – Addditional external test, mock and test data. Unit test in Go in the same package as the source files.
/configs – Configuration files.
/docs – Deign and user documents.
/api – API contract files (Swagger, Protocol Buffer, etc.).
/examples – Example for our applications
/web – web application specific assets (static files, etc.)
/build – packaging and continuous integration (CI ) files.
/scripts – scripts for analysis, installation and so on.
/vendor – application dependencies (for example, Go module dependencies)
In any case, we must bear in mind that, regarding project structure, there’s no mandatory convention.
For example :
A book reviewing service
Users can add a book.
Users can add a review for a book.
Users can list all books.
Users can list all review for a given book.
Options to store data either in memory or in a JSON file.
Ability to add some sample data.
Above mentioned service we if we use flat structure our project structure seems like
Organizing the project is not straight forward, hence try to make standard project structure in your organization so that developer don’t waste time switching from one repository to another. Standard project structure ensures that easy to understand, readability, maintainability, maintain consistency. Try to keep things consistent as possible with a codebase under project structure. It definitely, helps to organizing the project.
References :
Teiva Harsanyi,Go Mistakes and how to avoid them, Manning Publications Co
