Go Microservice with Clean Architecture |

I created a Microservice project with Go and gRPC and tried to figure out what is the best project layout, which can be used as a template for my future projects. I also tried to apply the best practice in application design and programming, such as Clean Architecture, Dependency Injection, logging, error handling and so on, to the Go Microservice application. I came from Java background and found myself keeping struggling between Java and Go idioms, which are quite different. I wrote a series of articles about decisions and trade-offs I made when working on the project.

Who is the audience?

Knowing basic Go is not required for reading the articles, but definitely will help you. If you don’t know Go and can’t figure what the code is doing, then you probably want to learn some basic Go from “Go by Example”¹ (You don’t need to finish all of the topics, just the first several). The “Transaction support” one in this series is database heavy and require some database knowledge in Go and you can acquire it from “Go database/sql tutorial”². If you are interested in Go Microservice programming and thinking about the code design and application layers, project structure, coding style, logging, transaction management and Dependency Injection, then this series is perfect for you.

What is it about?

The series is not about how to create a quick working prototype, but about how to create an application with a good design that easily adapts to changes, for example, you may want to split part of functions into a separate Microservice, or add transaction support after a business feature is up-running, or switch to a better logger, but don’t want to change every logging statement in your code. By applying the design in this project, business logic code is never touched when making the above changes. You seldom change any existing code (except for the container code), but only add new code, thus the QA effort was greatly reduced. You can use this application as the starting point to base your next application on. The only cost is to figure how different pieces of the application are wired together. If you have Spring (Java) background or coming from object-oriented paradigm, or know Clean Architecture or SOLID, the code should be pretty familiar to you.

You don’t need to read articles in the following order. If you are familiar with Clean Architecture³ or SOLID⁴, you can read the articles in any order without a problem. However, I do recommend you start from the first one, which will give you a overview of the whole project, then you can pick the ones you are interested in.