I'm creating a proof-of-concept for a Go-app for my organization. I've read all of the intro docs on setting up a Go workspace, packages, etc. However, I am still unclear about the relationship amongst the recommended directory structures, packages, AND the fully-compiled applications that will eventually be deployed.

My team needs to be able to support many small, decoupled, applications --I am not sure how I can achieve this with the single-workspace-multiple-package approach, and would greatly appreciate clarification.

1 Answer 1


I'll try to answer this with a simple scenario. Let's imagine you and I work together for a shipping company and we want to implement a SOA. We identified 2 separate bounded context in our domain, accounting and shipping; we decide to implement 2 separate, standalone, services (think micro services) for each bounded context.

I start working on the Accounting service and you tackle the Shipping service. A few months later, Bob joins the company and he's assigned to work on another service, Reporting. As a diligent employee Bob wants to keep his service consistent with the other services and so he looks at the existing services trying to find a pattern. However, he realises neither service is consistent to the other and both services contain a lot of boilerplate code. Bob raises his concerns about the approach used not being scalable. We need to be able to share and reuse boilerplate code.

This is where the Go workspace comes in. The idea behind having a single Go workspace across teams is to promote code reuse by sharing libraries.

Back to our scenario, we identified and grouped a lot of common functionalities in a library called utils. By placing utils in the single shared workspace alongside the existing services, each service can now utilise it as a library, therefore avoiding lots of boilerplate code and achieve consistency across services. Furthermore, this approach is scalable, as future services will be able to use the same library from the workspace.

You can see how this model is beneficial.

However, as we add more services to platform, we decide to use third party libraries for some of the more common tasks. We could manually copy and paste each third party library in our workspace, but this is definitely not an ideal approach.

Enter go get. go get is a Go tool, part of the Go stdlib. It works by downloading third party libraries needed and store them in $GOPATH/src/, in a particular format (package source). The cool thing about this is that we could take advantage of using the same tool for all our shared libraries developed internally (e.g. the aforementioned utils). All we need is to name all our libraries and services with a fully qualified domain name, such as github.com/ShippingX/accounting & github.com/ShippingX/utils, et voila! We can now reuse our utils library just by typing go get github.com/ShippingX/utils on the command line. Pretty cool.

However this is still not perfect and has a big issue: dependency management. This is the reason why Go is now moving towards abandoning the workspace in favour of, what they've named, modules. With modules we will no longer need a $GOPATH, but instead, we will need to specify dependencies and their versions in a Toml file, and using go get to download them.

Hope this helps! I'd like to point out that this is just a reflection purely based on my experience in working with Go for a few years. YMMV.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.