Go project layout
Tags: programming, productivity, go, beginners
Published: 2021-02-08 12:36:09

Go is very flexible when it comes to writing apps and structuring them.
Though, you should always write idiomatic Go when possible.

While not thinking about structuring your apps is okay, but as your app starts to grow, you have to have a structured architecture so that it's easy for you and other devs to know how things connect in your app. It also avoids duplication of code and, maybe, will help you scale heights.

I was looking for that one structure I could follow, but almost everyone has their stuff.
So, I started reading blogs and even started reading open-source projects and finally picked the best parts.
Before showing you the structure, I'll try to build your mental model for this architecture by this analogy.

Let's say you want to start a business and the product your building is a Dancing Doggos App, which will contain dancing videos and photos of dogs.


Exciting right?

![Dancing Doggo](https://media.giphy.com/media/OnQqgkPWJ17DG/giphy.gif)


Now, what should we do next?

The first that comes to my mind is management that can manage our product specific to our needs.
So we need to hire product managers, CEO, CTO and other fancy managers with those suits and ties :p

Next, we need is the people who'll be working under our Managers. 
So, marketing team, sales team, and a team of amazing people aka developers :p

Now that we have everything ready to go, we need to think about how everything will work.
The following few lines are going to be the crucial part of all the useless stuff I wrote.

#### Product Owners - 

- They want their idea out in the market.
- They only talk to the managers.
- They don't care how you do it ( of-course not if its unethical :p)

#### Managers - 

- They are the people who are responsible for getting the work done.
- They manage the people working under them to work according to the needs
- Their work is mostly product specific.
- Their decisions and choices are governed by the product they are building. (A Manager who is working for Pepsi will have to make different decisions if he starts working for Gucci) 

#### Teams - 

- They usually don't care what you are building
- They usually don't have to change their decisions based on the product (A Go Developer working on Go in Pepsi will also be working on Go if he makes a switch to Gucci).
- Teams are usually independent and don't require any other team to make their work done. ( Marketing team doesn't depend on Devs team to work)

You might be thinking I have read so much and still haven't found anything I can take away from this but please bear 🧸 with me for the next few minutes.

Building upon our business workflow, we can structure our app. 

![structure](https://dev-to-uploads.s3.amazonaws.com/i/wkdj3gs22mpvqxyklvcl.png)

## /app

*Product owner*

This folder contains our business logic, and that's it. 

This directory doesn't care about what database driver you are using or which caching solution your using, or any third-party apps.

Its only job is to provide the business-related details, including structuring the models, authorizing the clients, storing them in the database, or sending it to the clients.

## /platform

*teams*

This folder contains all the platform-level logic that will build up the actual product, like setting up the database, Redis instance, or maybe a router.

All of the packages inside this directory are independent of each other.

Packages inside this folder also don't care what's inside **/app**  or **/cmd**

## /cmd

*Management*

This folder contains all the application-specific code tailored only for your business use case—things like configuration, logging, and DB migrations.

This directory talks to the  **/app** for instructions, and then it takes the services offered by **/cmd** and finally delivers the product
This directory is the Mitochondria of our application (Bad science pun, sorry :p)


___

### tl;dr

Your app's business-related logic shouldn't care about the platform and app-level code like routes, databases, and third-party packages you are using.
Your Application-level code (/cmd) like configurations and routes will vary according to different services or business ideas.
Your Platform level code doesn't care what you are building, and they should only have a single purpose. It shouldn't produce any side-effects inside your business logic.


Here is the WIP project uses the above structure

The project below is just a work in progress and only for my learning purpose, but the structure is handy if you want to use it in your next project.

[https://github.com/royalbhati/url-shortener](https://github.com/royalbhati/url-shortener)