Writing clean Golang Services

The article author has been all over the internet searching for a pattern to allow him and his team to use a consistent pattern, giving consistency across the board so all the engineers know where to find things and where to get up to speed quickly as well as testing capabilities, isolation, portability and a ton of other things.

So far I’ve not found a pattern that can cleanly give me this, I’ve looked at the factory, builder, options, hexagonal, and a ton more, but none have given me what I want, but I have found a nice place to structure a pattern and would like to introduce it to the wider industry.

The solution I have found is to take the ideas from the ports and adapters pattern and the hexagonal architecture and simplify them somewhat to this:

The core package

So the core package in Golang is acting as a manager for the service, holding the simplest to understand the business logic of the application, this is a starting point for any new developer touching the service to quickly understand what it does and what it is for.

If you want to imagine the service as a team of people, the core package is the manager, a high-level coordinator responsible for coordinating and directing the request as it comes through.

This also holds another advantage of gRPC services as you need a structure to hold the RPC server anyway and most input to an RPC action is a context and a structure pointer, this translates easily to this format.