Nowadays we can often hear that monolithic architecture is obsolete and responsible for all evil in IT. We often hear that microservices architecture is a silver bullet which helps to kill all this monolithic evil. But you probably know that there are almost no silver bullets in IT and every decision entails trade-offs. One of the most favored advantages of microservices architecture is good modules separation. You can deploy every service independently and services are easier to scale.

In case you’re here for the first time, this post is the next in our Business Applications in Go series. Previously, we introduced Wild Workouts, our example application built in a modern way with some subtle anti-patterns. We added them on purpose to present common pitfalls and tips on how to avoid them. In this post, we begin refactoring of Wild Workouts. Previous articles will give you more context, but reading them isn’t necessary to understand this one.

Do you know the rare feeling when you develop a new application from scratch and can cover all lines with proper tests? I said “rare” because most of the time, you will work with software with a long history, multiple contributors, and not so obvious testing approach. Even if the code uses good patterns, the test suite doesn’t always follow. Some projects have no modern development environment set up, so there are only unit tests for things that are easy to test.