Organizing code into packages

As we saw in the previous section, the application of the SOLID principles works as a guide for splitting our code base into smaller packages where each package implements a specific bit of functionality and its interfaces serve as the glue for wiring packages together when building larger systems.

In this section, we will be examining the idiomatic Go way for naming packages, as well as some common potential pitfalls you may encounter while authoring code that relies on a complex package dependency graph.

Naming conventions for Go packages

Let's say you come across a package named server. Is that a good name, as per the preceding suggestion? Well, obviously, we can guess that it's...